################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally published in the Proceedings of the Fourth Annual Tcl/Tk Workshop Monterey, California, July 1996 For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org A Clinical Neurophysiology Information System based on Tcl/Tk Martin B. Andrews and Richard C. Burgess Section of Neurological Computing Department of Neurology The Cleveland Clinic Foundation 9500 Euclid Ave Cleveland, OH 44195 andrewm@ccfadm.eeg.ccf.org Abstract The Department of Neurology at the Cleveland Clinic has replaced a restricted patient information system with a new one based on Tcl/Tk. Tcl/Tk along with several novel extensions provides the base for creating portable client-server database applications. These extensions and some of the clinical applications are presented. 1. Introduction The Cleveland Clinic is a large multi-specialty medical center with a high volume of both inpatient and outpatient evaluations. One of the largest departments, Neurology, is a leader in the care of patients with epilepsy and other neurological disorders. Along with physical examinations, imaging studies and laboratory tests patients are evaluated with neurophysiological tests like EEG (brain wave tests) and PSG (sleep tests). Tests are performed using computer-based acquistion and review systems developed by the Section of Neurological Computing. This section is reponsible for the information needs of the department, and provides networked databases to physicians, nurses, technologists and secretaries. These systems and software products have also been made available for use at other institutions through the Vangard subsidiary. The Neurology department's patient information system, EBase, was integral to daily operations and research studies. It was also unreliable, difficult to use and even more difficult to program. A major overhaul of the code was enacted to remove bugs and hardware dependencies. The resulting system, EBase2, was more reliable but development was still painfully slow. Particularly hard to develop were the highly customized user interactions demanded by our users. To overcome this problem a radical redesign of EBase was initiated. Informix-4GL, the proprietary programming language used in earlier revisions, was dumped. The requirements for the new EBase3 were as follows: Rapid Development - The burgeoning development of new clinical tests, a desire for faster reporting of test results and a need to reduce costs drive an ever growing demand for information to be maintained by EBase. In addition, vague user requirements necessitate quick prototyping. Programmers must be able to quickly extend EBase. Ease of Use - Our users demand an intuitive and stream-lined user interface. These somewhat contradictory needs can be met with flexible user interface components that are customized for particular groups of users. Even further flexibility is required if other institutions are to use EBase. Portability - Departmental users access EBase from Unix workstations, PCs running Microsoft Windows, and Wyse 60 terminals attached to a Unix server. All of these devices must be supported. For EBase to be used at other institutions it must be portable to even more client devices, and even a variety of server platforms. Simple API - The section of neurocomputing also develops software to acquire and review neurology test data. A simple API for accessing the EBase database is desired for use in these systems. Inexpensive Licensing - The cost of development tools was an important issue because of our own budget limitations and, more importantly, the need to provide a competitively priced package to other institutions. Even tools without run-time fees generally charge per target platform - a problem considering the number of targets to be supported. The resulting design for EBase3 uses Tcl to help meet these goals. The core of EBase3 is an extended Tcl interpreter called Clavier. Clavier controls all access to the patient database. It enforces data integrity rules and hides implementation details of the database schema. Only Clavier sends SQL commands to the database engine. Clients send requests to Clavier via TCP/IP in the form of Tcl commands. The client itself does not require a Tcl interpreter, but the most common client is an extended Tcl interpreter called Bach. Bach is a generic tool for building GUI database applications. Applications for Bach are Tcl scripts. A version of Bach exists for X based workstations, and character terminals connected to a Unix server. A version for Windows based PCs is being developed. Clients that do not include a Tcl Interpreter use a small C library to send Tcl requests to Clavier. The components of EBase3 are depicted in figure 1. The design uses the three-tiered architecture being embraced by packages like PowerBuilder[1]. An elegant feature of the EBase3 design is that the Bach client can load all the Tcl code from Clavier. This feature simplifies maintenance by providing a single point of installation, and allows easy operation over a wide area network. The remainder of this paper consists of three major sections. Section 2 describes the Tcl extension packages used in the Bach server and client. Section 3 presents some applications implemented using the Bach client. Section 4 concludes with observations from the EBase3 project. 2. Tcl Extensions Clavier and the Bach client include many Tcl extensions to simplify the creation of an information system. Both Clavier and Bach include the object-oriented programming extension OTcl [2]. The PC and workstation versions of Bach include Tk as the basis for their user interface. The character terminal version of Bach includes CTk, a curses based replacement for Tk that is discussed in the next section. All Bach versions include the table geometry manager from BLT that simplifies the layout of forms, and Stephen Uhler's HTML library for rendering formatted text. In addition to these outside-developed extensions, several new extensions have been developed at the Cleveland Clinic. These in-house extensions are presented in the following subsections. 2.1 CTk Curses Tk, or CTk, is a replacement for Tk that displays to character terminals. The user interface is navigated using keyboard bindings mostly compatible with Tk (some differences occur because most terminals do not support the range of modifier keys used in Tk). While not as pleasant to use as Tk, CTk provides an important fall back when Tk cannot be used. Besides the obvious case when only a character terminal is available, CTk has also proven useful for remote access. A screen snapshot of the EBase3 schedule application running under CTk is shown in figure 2. Like Tk, CTk is written in C except for event bindings, which are defined in Tcl. CTk supports the majority of Tk commands, but the differences require existing Tk applications to be modified to run under CTk. It easy to write applications that will work with both Tk and CTk if this goal is considered from the outset. For an application to be portable to Tk and CTk, the most important requirements are resolution independence and support for small screens. These attributes are useful even for applications solely intended for Tk. 2.2 Rdb Rdb provides a Tcl interface to relational databases. Currently, Rdb only provides an interface to Informix. Rdb is loosely based on DBI [3], the universal database interface being developed for perl, so it is intended to interface with a variety of database engines. An example Tcl script using Rdb is shown in figure 3. Rdb includes the flexible error handling scheme from DBI that supports recovery from failed database commands. It also supports access to BLOBs. Rdb is implemented entirely in C. informix connect myConn "mydatabase" myConn prepare mySelect { select id, first_name, last_name from employees where last_name matches ? order by last_name, first_name } mySelect execute A* while {[mySelect into vals]} { puts "$vals(id) - $vals(last_name), $vals(first_name)" } 2.3 Bach The Bach extension is a library of database utilities us ed in both Clavier and the Bach client. It defines network commands and OTcl classes for domains, fields, forms and reports. Bach is implemented in a mixture of C and Tcl. The Bach network commands provide a simple method for sending Tcl commands via TCP/IP. In addition, the Bach library includes a short wrapper for the Tcl source command that allows the Bach client to auto-load Tcl files from Clavier. Domains are OTcl objects that provide easy access to a database. A domain represents a set of member values, and defines a list of attributes for its members. Each attributes itself has an associated domain. For example, date is a domain and one of its attributes is year. The domain of the year attribute is integer. In addition to algorithmic domains like date and integer, Bach includes the SqlTable class for domains representing the rows of a relational database table. Bach automatically defines parameterized types like character(20), the set of all character strings with length 20 or less, by patching the unknown Tcl command. Domains also specify default fields, forms, and reports for depicting members of the domain. Fields are widget classes that can take on any value from their assigned domain. All fields provide methods for storing, retrieving, and validating their value. Forms are mega-widget classes containing one or more fields. A simple form layout can be generated automatically, or an intricate layout can be specified explicitly. The Report class provides the basis for generating HTML formatted reports. Using HTML provides a natural method for browsing records in the database. HTML is used for all formatted text in EBase3, removing the need for separate code for printing or viewing a record. To facilitate printed reports, non-standard mark-up tags and attributes are used to control features like page breaks and page orientation. A custom HTML formatter interprets these non-standard notations and outputs the report in PostScript, HP-PCL, or ASCII format. The HTML report formatter is an independent program implemented in C. 3. Applications EBase applications are Tcl scripts executed by the Bach client. These applications share a common library of Tcl code that defines domains specific to EBase, and their associated user interface components. The EBase library currently consists of 8000 lines of Tcl code, over half of which is for the complex domain representing neurology tests. Neurology tests have thirty attributes including complex items like findings and classification that contain many attributes themselves. The actual format of these complex attributes is determined by the study type of the test. The neurology test form is depicted in Figure 4. The Patient application, shown in Figure 5, provides easy access to all EBase records associated with a single patient. Users are presented with the patient demographics and a concise medical history. Selecting a history entry opens a hypertext browser. At any point, a form can be opened to update or add new patient records. The schedule application, shown in Figure 6, presents neurology tests by the date they were performed. In addition to scheduling or rescheduling tests, the user can enter the hypertext browser by selecting one of the entries. In addition, the schedule application provides a collection of administrative reports. Both of these applications are short Tcl scripts: the patient script contains 221 lines, the schedule script 376 lines. 4. Conclusion EBase3 has succeeded in creating a portable information system that is easy to use and extend. It is in production use in an environment that schedules 800 tests per month and averages a dozen active users. The new system has been greeted enthusiastically by a wide range of users including secretaries, technologists, physicians, and staff in training. The tools created for EBase3 have also shown promise for use in other information systems. Clavier and the Bach client were used to create a modest application to generate project status reports. This application manages six database tables, and includes five forms and one report. It required only 550 lines of Tcl code. I initially considered Tcl for use in EBase3 not because of any attribute of Tcl itself, but because of the Tk Toolkit. While the Tk toolkit has succeeded in providing a rich user interface for EBase3, Tcl itself has proven well suited to departmental information systems, where rapid development is usually more important than blazing performance and most of the work consists of string manipulation and interacting with the user. The main problems discovered with Tcl are listed below. Performance - While performance was not the main concern in EBase3, there were times where Tcl was too slow even for high level functions. Performance problems have been overcome by recoding commands in C, but this is not an ideal solution. In addition to the greater development effort required by C, C code must be built and installed on all of the client platforms. Tcl code only needs to be installed on the Clavier server. The eagerly awaited on-the-fly Tcl compiler will hopefully solve this problem. Tight integration with Java is another possible solution. Development Tools - GUI development tools for Tcl would further the goal of rapid application development, and greatly assist in bringing new programmers up to speed. The SpecTcl project [4] at Sun Labs addresses the need for a GUI builder. A source browser (supporting object-oriented programming) and a debugger are also needed. Production grade tools are a must. References [1] Powersoft, Building Distributed PowerBuilder Applications, Powersoft, Concord, MA, 1995. [2] David Wetherall and Christopher J. Lindblad, Extending Tcl for Dynamic Object-Oriented Programming, 1995 Tcl/Tk Conference Proceedings. [3] Tim Bunce, Perl 5 Database Interface (DBI) API Specification, Draft Version 0.6, 1994. [4] Stephen Uhler, A Graphical User Interface Builder for Tk, 1995 Tcl/Tk Conference Proceedings.