W3 Based Medical Information Systems vs Custom Client Server Applications


K.E. Willard* M.D. MSEE
J.H. Hallgren** B.S.
D.P. Connelly M.D. PH.D.

**Presenting Author
*Corresponding Author
Box 609,
Mayo Building
Medical Decision Support Group
Division of Laboratory Information Systems
Department of Laboratory Medicine & Pathology
420 Delaware Street
University of Minnesota Hospital and Clinic
University of Minnesota, Minneapolis, MN
55455

Abstract

The Medical Decision Support Group at the University of Minnesota Hospital and Clinic (UMHC) has previously developed and deployed custom client-server applications (NEXTSTEP based) that access hospital SQL databases for use by clinicians on the hospital ward. Although well received by clinicians, it was difficult to proliferate these applications in our institutional environment. An alternative architecture built on W3 has been developed that directly addresses these constraints.

The key to delivering a W3 alternative has been to create HTML documents on the fly, retrieving patient specific information from our SQL databases at the time the request is made. A request for a given document is actually an invocation of a Perl script that performs database retrievals and creates the HTML document for display by the W3 client.

We have found this Perl/SQL/W3 client-server architecture and development environment to be surprisingly and extraordinarily productive. Responsiveness of the system has been comparable to our custom application. The customization and functionality obtainable with the HTML document/W3-client architecture is less than that achievable with a totally custom application client but has been deemed in pilot studies to be satisfactory.

The use of the W3 server-client environment when coupled with the concept of dynamic document creation driven from standard network SQL repositories opens highly productive horizons for medical information system developers.

Introduction

The modern hospital can be likened to an information factory. Individuals, sections and departments generate reams of information, much of it electronic, yet its delivery back to the key clinical decision makers is cumbersome, slow and poorly coordinated. Thus useful electronic information may disappear into information "sinkholes" that are either too unfriendly, awkward, or slow to be clinically useful. The amount of on line information that is generated is impressive. It is estimated that clinical laboratory information alone accumulates at the rate of .5 MB per patient per day in our institution. The other large scale information generators that are on line include radiology, pharmacy, admission discharge transfer tracking, and of course the all-important patient financial billing and accounting systems. The physician and nursing record systems are usually still paper based in most hospitals.

Unfortunately, such an information rich generation environment is not well served by existing information dissemination technologies. Seasoned observers of the hospital information systems (HIS) field comment that the commercial information technology runs at least five years behind that in the general business sector. As in other sectors, the product of information technology vendors may lag behind the needs of the potential of technology by a decade [Bourke ]. One indication of this is that none of the top three (by market share) hospital information system vendors has adopted a client server approach. Each is still relying on COBOL programs running on expensive main frame systems driving terminals that deliver extremely inflexible (and ugly) user interfaces. Virtually any new reporting requirement that comes along requires custom programming and a sizable in-house or contracted programming staff. It is not uncommon for waiting queues for such new services to be in the months or years.

There is a strong need to go beyond making information available in a user friendly and universal fashion to make knowledge available by "activating" it. In a narrow sense we mean by this the embedding of expert systems into otherwise ordinary on line transaction information systems. This makes it possible for institutional practice patterns or guidelines to become "default" behavior when generating clinical orders in the patient care areas.

Custom Client Server Medical Information Applications

In a UNIX workstation environment

We addressed some of these problems in a series of pilot projects at UMHC that relate to the development of a physician/clinician workstation (CWS)[ Connelly DP et al ]. The first phase of this project was the creation of a network accessible SQL server "front end" to our legacy COBOL-based laboratory information system (LIS). Using the HL-7 transfer standard we connected our LIS to a Sybase SQL Server running over TCP/IP. We disseminate laboratory test orders and completed test results to and from the client workstations to the server via the hospital's ethernet backbone.

The second phase of this project was the development of workstations that piloted a user friendly display of laboratory information coupled with a prototype embedded expert system for ordering high cost laboratory resources (blood products). Because our development group was small and the project was a pilot effort we used the NeXT OOP development environment to craft our user interface. The NeXT Interface Builder tools along with their rich object class libraries provide what many feel represent the current state of the art tools to create graphic user interface designs. An example of the kind of user interface we developed for laboratory data is seen in Figure 1 .

While the CWS project has been technically successful and warmly received by our clinician users our institutional administrative environment has been unfriendly to proliferating what it viewed as a non standard platform. This largely political barrier caused us to radically rethink the way we were viewing the application development environment. This retooling led us to consider the Web[ Berners-Lee et al , Schatz et al ]

Development of Web Based alternatives to Custom Client Applications

The present key to using the Web environment to access institutional databases involves the Web server common gateway interface (CGI). The CGI provides a mechanism whereby a programmer can create programs or scripts that are accessed in lieu of a static HTML document. These scripts access patient specific information from the network SQL servers. They then dynamically create on standard output the HTML document requested by the user working at their W3 browser.

At the present time our principal tool for this task has been Perl [ Wall, Schwartz ]. Perl's strengths as a CGI script environment include its rich text manipulation capabilities, short development cycle, portability, database access extensions (sybperl, oraperl), adequate performance, and its process manipulation tools. It is also an easy language to pick up for UNIX based C programmers.

This interface link along with the basic forms capability, provide a basic set of control devices required for custom client server application development. Figure 2, demonstrates an equivalent Non-functioning page from our web based patient laboratory results display application.

Advantages of the W3/SQL/Perl approach

The combination of W3 with institutional SQL data repositories and the use of Perl as the integrating CGI script offers a number of very significant advantages to medical systems developers. Among these are:

Reduction in work needed to deliver information

If the required functionality of the application can be achieved within the existing W3 constraints the productivity gains in the application development cycle can be astonishing. In porting our custom client NEXTSTEP functionality over to web we found even crude estimates showing at least 1:10 reduction in terms of lines of code per window (page). There was also a reduction in code "complexity" in that much of the Perl code revolved around fairly low intensity issues. In other words we wrote fewer lines of code to deliver approximately the same functionality and we could write more (and debug more rapidly) code per day.

Many of the productivity gains occur simply because we were able to stay relatively distant from the client. Thus, many client side issues simply disappear from the application developers development schedule such as:

Given the availability of W3 browsers, we simply ignore these client issues and they automagically go away.

Multiplatform Delivery

Our environment includes the desire to deliver browsers for MS Windows, X-Windows, the Macintosh, and our NeXT boxes. Our application to date involves relatively plain vanilla W3 work (forms but no animation, no sound, few graphics). In this setting we have found reasonably good cross browser results with the primary inconsistencies cropping up because of the lack of table formatting controls.

Ease of integrating dynamic data with existing static documents

We believe there are many medical data presentation problems for which any printed form provides an unsuitable representation. Many of these problems, such as the general presentation problem faced in clinical microbiology, is well suited to the hypertext method of structuring the data.

While the core of our hospital information needs revolve around the requirement to display dynamic patient specific information, the ability to seamlessly integrate previously paper based documentation is an outstanding advantage of the Web environment. Figure 3 demonstrates our antibiogram display from our microbiology display module. An antibiogram is a special clinical report used by physicians to determine the best antibiotic choice for treating a given infectious organism. Antibiotics which are restricted (subject to obtaining an infectious disease consult) are linked to the official hospital Pharmacy and Therapeutic Committee documents for these drugs, Figure 4 , Figure 5 . These documents explain why they are restricted, their specific costs, and the appropriate clinical setting for their use.

Previously clinicians neither had access to the antibiogram or to the Committee documents which were distributed to a few people and promptly filed away in the circular bin. Now this information is universally available to clinicians and available in the context of a specific patient's antimicrobial laboratory sensitivity results.

Debugging

So far our development work has not required anything more than Perl or a combination of Perl and Tcl. (Tcl [ Ousterhout ] is being used to implement our required inference engines). Consequently our debugging environment consists of a W3 browser open in one window, and an editor window open on our Perl script in another. Make a change in the script and hit document reload on the W3 browser. The W3 browser we use most commonly for development (Omniweb) dumps Perl's standard error into the browser window so we either get a HTML document or we get our Perl error messages. No compiling, no linking, no make management. It is possible to do a few hundred debug iterations a day compared to the handful of compile link cycles we could accomplish with our large integrated client application.

Economics

For in house custom software development the current W3 tool technologies are very attractive. In addition to our institutional servers (SQL), our basic technology set requires W3 browsers, Perl, and Tcl. These tools are all available from standard ftp sites.

Present limitations

Every enthusiastic web development group has its own enhancement list, and we are no exception. Here are the particular limitations we have encountered in creating our web applications as compared with our custom client server development environment.

Restricted GUI functionality

Far and away the biggest difference confronting a developer who moves away from a custom client development to using W3 is the restricted variety of user interface design tools available. The use of W3 as a full fledged application development environment is still pushing the envelope at present, but here are a few of the existing restrictions we chafe under and a few goodies we would love to see.

Existing restrictions:

Features we would love to see added to the browsers:

Session oriented security problems.

The connectionless philosophy of HTTP creates problems that have to be worked around when implementing applications that need to imbue security and permissions across time. For example on a typical patient care area up to 70 different people may use the same machine during the course of the day. We need to "time out" our documents (document expiration is not yet supported by the browsers in our use) to force re-authentication. Furthermore, once a user is authenticated we wish to avoid reauthentication as the user moves from page to page unless time has passed and no usage from the machine occurs. We presently create this state information outside of the web environment (for example as a time stamped security ticket in a database table) which is rechecked with every new server invocation.

Reliability of Browser and Browser Environments

Compared to the NEXTSTEP/UNIX application/operating system environments the MS Windows and Macintosh environments still have a long way to go in terms of 24 hours a day reliability. Furthermore since we are pushing the edge of what we can do in W3 we have been eager to use the most recent alpha releases of the W3 browsers. This all leads to reliability performance that is considerably less than what we have been able to achieve with custom UNIX applications. We can expect the present circumstances to improve.

Conclusions

We have moved a traditional client-server database intensive clinical application from a wholly custom client to one based on W3. The key to allowing W3 to act as our integrating front end is the use of CGI scripts to gather institutional SQL data. While we have found distinct limitations to the present W3 architecture we have been gratified at the very high productivity levels we can achieve within these constraints. It is not only possible to create W3 applications in the medical environment that are competitive to custom client application development but it is possible to do it with fewer people in less time and for less money while gaining client platform independence as well.


References