Object-Based Approach

Transcription

1 User-Specific Interfaces for Clinical Data-Management Systems: Object-Based Approach An Richard Wilton, MD UCLA Department ofpediatrics ABSTRACT Multiple user-specific visual interfaces are desirable in any computer-based clinical datamanagement system that is used by different people with different jobs to perform. The programming and maintenance problems ofsupporting multiple user interfaces to a single information system can be addressed by separating userinterface functionality from data-management subsystems, and by building user interfaces from object-based software components whose functionality is bound to an underlying server-client data-management architecture. Experience with this approach in a patient-tracking system suggests that this object-based approach is viable in the design of a user interface for a clinical information system. Clinical data systems are tools that are used by many different people in the course of patient care. Physicians, nurses, students, and data-entry personnel need access to the same clinical data, but these different groups of people generally have different requirements for structuring database searches and for representing clinical data on a video screen. For a computer-based information system to be optimally functional in a clinical setting, the visual interface at the computer workstation should be adapted to the specific needs of the user. This requirement creates problems in the design of clinical software applications because the functionality of the visual interface must be coordinated with the underlying data-management system. For instance, a field-formatted database usually contains fields whose size is predetermined; the corresponding user interface to such a database must be designed so that the sizes of the fields displayed on the screen accommodate the field sizes in the database. Another instance of the coordination between the visual interface and underlying data management lies in the usage of data types. For example, the user interface to a database field that contains a date must be designed to display the date data in a particular format, and to allow only certain kinds of formatted user input to the field. Such low-level constraints can make it difficult to tailor a user interface to the specific requirements of different users in a clinical setting. The problem is compounded by considerations of adaptability and ongoing maintenance of the user interface. Clinical information systems change and grow in response to user requirements, so the ability to modify or adapt the visual interface in a computer system is essential to its success as a useful tool in a clinical setting. One approach to user-interface flexibility in the face of low-level data-management constraints is to rely on a menu-based user interface[l]. This approach allows different users to be presented with different menus and thereby gain userspecific access to a data-management system. The problem with the use of customized menus is that such an approach does not fully satisfy the requirement to display data in a user-specific visual context. Another method of customizing a datamanagement system in a user-specific manner is to devise data-management subsystems that communicate with each other. Each data-management subsystem can then present its own user interface. This approach makes sense when the data in one subsystem derive sequentially from user interactions with another subsystem. For example, in a clinical-advice system where enduser interaction with the system can be sequentially separated from the knowledge-management interactions, different subsystems with different /92/$5.00 X)1993 AMIA, Inc. 265

2 user interfaces can handle the different kinds of interactions, and the underlying datamanagement functions can be sequentially coupled[2,3]. Neither of these strategies is entirely suited to the more common problem of maintaining different display interfaces for different users of a clinic information system. A more direct approach involves functional separation of the visual interface from the data-management system so as to modularize interface design. OBJECT-ORIENTED VISUAL DESIGN A reasonable way to separate user-interface design from data-management system design is to implement a set of "visual objects" that encapsulate the functionality required for the display and input of specific data items. In this context, the notion of an "object" is borrowed directly from the paradigm of object-oriented software design. A visual object embodies specific data-related functionality, including a visual appearance, data-formatting capabilities, and a link to an underlying data item or related set of data items. Essential to this design is that each visual object is functionally independent of the underlying data-management system. In effect, each visual object knows how to display its data, how to format its data and to detect user-input errors, and how to transmit its data to a data-management system. These functions identify data items using a naming scheme that embodies a level of abstraction that hides the details of the interface to specific database-management or remote-communications systems. IMPLEMENTATION A set of visual objects was developed in the context of a clinical patient-tracking system used in the pediatric outpatient clinics at the UCLA Children's Health Center. The system architecture consists of a number of microcomputer workstations attached to a local-area network. The network software embodies a server-client architecture, in which a databse-management system contains outpatient medical-record summaries, a communications link to a mainframe computer system provides patient demographic data, and an expert-system "rule server" provides real-time inferences regarding patient data[4j. The patient-tracking system has been operational since mid-1990 on 12 microcomputers in the outpatient clinics as well as in faculty offices in the Division of General Pediatrics. In the past 9 months, several user-interface adaptations have been created for specialized applications, including patient-tracking systems for division of pediatric hematology/oncology and for the Suspected Child Abuse and Neglect (SCAN) team. Physicians, nurses, data-entry personnel, and clinic administrators access the system by using one of the microcomputer workstations. Each workstation runs Microsoft Windows. Workstation application software relies on the graphic user interface integral to the Windows environment. Workstations communicate with servers using the NetBIOS protocol[5] and the Dynamic Data Exchange (DDE) protocol[6]. SOME VISUAL OBJECTS Four visual objects were developed for use in the outpatient clinic system described above. The visual objects used in workstation applications inherit functionality from the visual "controls" that are built into the Windows environment. The four object classes were named after the Windows control classes upon which they were based, as shown in Table 1. The visual appearance of each of the visual object classes is the same as the corresponding default Class Parent class X&isual appearance DBEdit Edit Alphanumeric text (can be modified by user) DBStatic Static Alphanumeric text (cannot be modified) DBListBox ListBox Scrollable list of one or more items DBCombo ComboBox Modifiable list of one or more items Table 1. Visual object classes as subclasses ofparent classes intrinsic to the WIndows operating environment. 266

3 Windows control class. For example, the visual appearance of the DBStatic object is identical to that of Windows' default Static control--a simple string of alphanumeric text that cannot be modified by user input. Thus, a user who is familiar with Windows' graphical interface can immediately manipulate data presented in one of the visual objects. The visual objects are implemented as subclasses of the default Windows controls. This allows them to be used interactively as building blocks in screen design, through the use of "dialog editor" software that manipulates them visually, without programming. New screen layouts are implemented, and existing layouts modified, without modifying application source code. An essential element in the functionality of each visual object is the establishment of a relationship between individual objects and data items. This is accomplished by using a generalized server-client communications mechanism based on a syntax derived from Dynamic Data Exchange (DDE). In the DDE protocol, a data item is uniquely identified by a hierarchical three-name specification consisting of a service name, a topic name, and a data-item name. In the context of a server-client architecture, the service and topic names identify the specific functionality provided by a server, and the dataitem name identifies a data item provided by the server in the context of the specified topic. In the current implementation, each visual object is associated with a delimited string that contains the service, topic, and item names for the data item displayed by the object. For objects that can display multiple items, an array of two or more strings is associated with each object. Agai these strings can be speified through the use of "dialog editor" software, so that no programming is required in order to create or modify the appearance of data displayed by an application. For example, to display a patient's last name, a DBStatic object can be used. The system implementor associates the DBStatic object with a particular data item by specifying a service name (such as CHC, the name of one of the database servers in the UCLA pediatric-clinic system), a topic name (such as PTS, the table of patient data maintained by the CHC server), and and item name (e.g., LASTNAME). The displayed formt of the object can also be specified, as shown in the following string: "CHC PTS ILASTNAME/name" In this example, the "name" format specifies that the DBStatic object is to display its data with initial uppercase letters, followed by lowercase. Similar format functionality exists for telephone numbers, numeric data, and dates. Inputformatting functionality can also be assigned to a visual object. For example, the following specification might be used with a DBEdit object to cause the object to accept and validate a birthdate as input using month-day-year ("mdy") format: "CHC PTSIDOB/mdy:mdy" AN IMPLEMENTATION EXAMPLE The following example shows how visual objects can be used to define different user-specific visual interfaces to an underlying databasemanagement system. The first screen snapshot (Figure 1, below) represents one of several "categorical" views of a patient-tracking database, in which a patient record can be viewed according to the categories of data contained in it. The example shows one child's weight, height, and head circumference for clinic visits on several different dates. Similar screens allow the user to view other categories of data such as "problem list," "current medications," and "immnizations." Zidemem iadumy Desd FlIt Date WEIks Hleman] OFCIcmI t l _.K a II Figure 1. A view of data in a patient-tracking database. A single visual object displays the database table containing date, weight, height, and head circumference. 267

4 Zzdemo, itsadummy Donotflil Encounter date: Clinic: Continuity (Wilton. Richard) Kmorminfiltm Weight (kg: 5.9 Height (cm): 41.5 OFC (cn): 42.5 New problems at this encounter. Otitis media, acute, right ear Medication changes: Amwxcillin 1 25mgScc Immunizations: (none) Assessment Otis media. acute, right ear Followup: PCC In 3-4 weeks for ear check 0K Figure 2. Another view of data in the same patient-tracking database shown in Figure 1. Several different visual objects are used to display the data. j Figure 1 shows a screen that contains a DBCombo object that is bound to a database table containing four different database items (date, weight, height, and head circumference). In the clinical system from which this example was obtained, the specifications for service, topic, item, display format, and input format were "CHC ENCSIDATE/mdy:mdy" "CHC ENCSIHEIGHT/number:kg"l "CHC1ENCIWEIGHT/number:cm" "CHC ENCSIOFC/number:cm" The category-based view of the outpatient record illustrated in Figure 1 is most useful for dataentry personnel, who must enter certain kinds of data (such as immunization data) for a series of dates, and for administrative personnel, who need to review the dates and locations of multiple clinic encounters. However, physicians and nurses may prefer a different view of the same data, in which all the data relevant to a single clinic visit can be displayed at one time (Figure 2). In Figure 2, different categories of data are aggregated on a single screen that represents a single clinic visit. Several different visual objects are used in this screen design, including DBStatic objects for the patient name and date of clinic visit, and DBListBox controls for the list of new problems and medications started on the visit. Some of the data elements in the underlying database-management system are the same in Figure 2 as in Figure 1, but the visual context in which these data are displayed is quite different. DISCUSSION The notion of applying principles of objectoriented program design to user-interface design originated in the mid-1980s[7]. A variety of user-interface management systems (UIMS) have appeared since that time in many different operating environments, including Unix (X- Windows and the NeXT computer), the Apple Macintosh, and MS-DOS (Microsoft Windows). As application developers gain experience in user-interface design, the importance of implementing appropriate visual tools for specific user applications has influenced the nature of software-development technology [8,9]. In the implementation described here, the design of "visual objects" embodies all three aspects of the dogma of object-oriented programmingencapsulation, polymorphism, and inheritance. Visual objects encapsulate both data and functionality such as displaying formatted data with an appropriate visual style, transmitting data to and from a data-management system, and validating user input. Visual objects also illustrate polymorphism in that each of the four visual-object classes behaves differently in regard to the same generic calls to display data or to transmit data to the data-management system. 268

5 Finally, visual objects inherit much functionality (in particular, their visual appearance) from the classes of visual controls defined in the Windows operating environment. The design of the four classes of visual objects relies on elements of object-oriented design (such as support for message passing and for object classes and subclasses) that are intrinsic to the Microsoft Windows environment. In the example above, the source code for the visual objects and the application software that used them was written in the C programming language. We have also written two different interfaces using the Visual Basic UIMS[10], which allows methods written in a dialect of the Basic programming language to be associated with visual objects. In both situations, the fact that the visual objects we used relied on system functionality intrinsic to the operating enviornment was advantageous both in terms of source-code design and in performance. A disadvantage to the use of visual objects in real-world application design is related to the use of an object-oriented design approach in an operating environment that does not fully support the object-oriented programming paradigm. This leads to certain amount of ad hoc softwaredesign, in particular where object design relies on the use of procedural programming interfaces. The current absence of a standard programming interface for database programming is particularly frustrating. To some extent, it might be possible to "hide" such problems by programming in a language such as C++, which more explicitly supports encapsulated objectoriented programming techniques than do C or structured Basic. Nevertheless, despite this problem, visual objects can serve as useful tools in the design of a user-specific visual interface. CONCLUSION Certain features of object-oriented software design can be valuable in the context of userspecific interface design for a clinical information system. In particular, it is possible to design a set of visual objects that encapsulate both a specific visual appearance and a confgurable, object-specific relationship to an underlying datamanagement system. A set of such objects can be used to design and maintain multiple userspecific visual interfaces in a clinical information system. References 1. HAmmOND WE, STEAD WW. Adopting TMR for physician/nurse use. Proceedings of the Fifteenth Annual Symposium on Computer Applications in Medical Care. Washington DC: [EEE Computer Society; 1991: TsuJI S, SHORTLIFFE EH. Graphical access to medical expert systems: I. Design of a knowledge engineer's interface. Meth Inform Med 1986;25: LANE CD, WALTON JD, SHORTLIFFE EH. Graphical access to medical expert systems: II. Design of an interface for physicians. Meth Inform Med 1986;25: WILTON R. Non-categorical problem lists in a primary-care information system. Proceedings of the Fifteenth Annual Symposium on Computer Applications in Medical Care. Washington DC: IEEE Computer Society; 1991: IBM local area network technical reference. Document SC Microsoft Windows software development kit: reference. Redmond, WA BARTH P. An object-oriented approach to graphical interfaces. ACM Trans on Graph 5:142 (1986). 8. THE UIMS TOOL DEVELOPERS WORKSHOP. A metamodel for the runtime architecture of an interactive system. SIGCHI Bulletin 24:32-37 (1992). 9. RETTI M. A succotash of projections and insights. Communications of the ACM 35:25-30 (1992). 10. Microsoft Visual Basic Language Reference. Redmond, WA