Integrating medical expert systems, patient data-bases and user interfaces

Journal of Intelligent Information Systems, 7, 261-285 (1996) © 1996 Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.

Integrating Medical Expert Systems, Patient Data-Bases and User Interfaces

MARIA TABOADA elchus @usc.es

Departmento de Electrdnica y Computaci6n, Universidad de Santiago de Compostela, Spain, E-15706

ROQUE MARfN

Departmento de Informdtica y Sistemas, Universidad de Murcia, Spain, E30071

J, MIRA

Departmento de Informdtica y Automdtica, UNED, Spain, E28040

RAMON P. OTERO

Departmento de Computaci6n, Universidad de La Coru~a, Spain, E15071

Abstract. Expert system applications in the clinical domain have not been very popular for lack of an adequate integration with other applications used in clinical environments. In the last few years, there is a growing trend towards the introduction of knowledge based systems as systems embedded in conventional applications. In this paper we propose an integration strategy of an expert system in oncology therapy with a clinical history data base and a user interface adapted to the needs of the medical environment. Our objective has been to design a system that is easy to use and provides all functions needed by the medical staff. The final system has consisted in first integrating three development tools and then using them in order to construct the complete application. The result is a global tool for the development of clinical information systems with embedded intelligent modules.

Keywords: User Interfaces, Medical Expert Systems, Embedded Intelligent Systems

1. Introduction

The difficulties for the acceptance of medical expert systems in clinical environments are well known. One of the critical factors in this respect is to carry out an adequate integration with other applications. An expert system that is integrated with a standard data-base and endowed with a good user interface is undoubtedly more attractive to its potential users. In general, a software environment is more effective if its different components are integrated (Thomas and Nejmeh, 1992). In the last few years, different authors have paid special attention to this aspect. Autio et al. (Autio, Kari and Tikka, 1991) integrated a knowledge based system with a patient data management system that was already present in the hospital. The basic objectives were to simplify the input of data to the expert system and to improve the conventional functionality of the patient data management system. Linnarsson (Linnarsson, 1993 integrated a controlled vocabulary, a patient database and a medical knowledge base in order to obtain a totally integrated decision support system and this way improve its acceptance by the medical staff. Berman et al. (Berman, Cullen and Miller, 1993) built a knowledge based prototype that automatically integrates external knowledge bases. The objective was to permit the incremental growth

262 TABOADA, ET AL.

of the knowledge available. Mulligen et al. (van Mulligen, et al., 1994) have proposed an integration architecture, HERMES, for combining preexisting data processing applications with data-bases in a local area network. Arkad et al. (Arkad, et al., 1994) are integrating a data driven decision support system in the HELIOS environment. In this case the integration is carried out taking the decision support systems as servers of the patient data bases and other medical applications.

Of course, the medical domain is not the only one in which there is a growing trend towards the introduction of knowledge based systems as systems embedded in conventional applications. In general, there is a drive towards the design of open architectures which easily allow the integration of specialized applications with preexisting conventional applications (Patil, Silve and Swartout, 1994, Jean, et al., 1994).

In this article we describe the strategy followed in the integration of an expert system for the production of advice in oncology therapy with a clinical history data base and a user interface that is specifically aimed at the needs of the medical environment. The general objective of our work has been to design a clinical information system that presents a cooperative behavior with the users of the medical environment and permits a flexible information exchange between the user and the system. We also wanted it to be easy to use by the medical staff and to be easy to adapt to different clinical environments and different users, providing flexible representation mechanisms that were simple to handle and which encompassed the different components of the system. An additional objective was to facilitate the direct participation of the domain experts in the process of designing and implementing the system.

The general strategy we have followed in order to obtain the final system has consisted in first integrating three development tools and then using them in order to construct the complete application. The development tools we chose were:

a user interface management system (UIMS) developed by our group, the MAGIT (Managing Graphic Interfacing Through Templates) system which is designed for fa- cilitating the development and production of user interfaces for medical expert systems and relational data bases (Marfn, et al, 1992, Taboada, et al., 1996).

• a relational data base management system (RDBMS); we have employed Oracle, but it can be adapted to other relational data bases using the standard SQL language.

a knowledge based system development tool, MEDTOOL (Otero, 1991, Barreiro, et al, 1993), which provides specific tools for the implementation of medical expert systems and, in particular, provides a model for handling temporal information that is adapted to the clinical domain.

The result is a global tool for the development of clinical information systems with embedded intelligent modules. We have employed it for the implementation of a patient follow up system in oncology where the patients undergo a protocol for the treatment of small cell lung cancer.

We begin this article with a general overview of the integrated tool and describing the criteria followed during the design, development and implementation of the applications (section 2). After this, in section 3, we will briefly describe the features of the clinical

INTEGRATING MEDICAL EXPERT SYSTEMS 263

Bypass

Figure 1. Seeheim's model

domain. Section 4 presents the architecture of the MAGIT system and its relationship with Seeheim's model. Section 5 and 6 detail the integration of MAGIT with the relational data base and the MEDTOOL tool, respectively. Finally, we describe the evaluation of the integrated application and present the results obtained in this evaluation.

2. General overview of the system

The integration of the RDBMS and the MAGIT and MEDTOOL tools has been carried out defining a general architecture that is an extension of Seeheim's model (Edmonds, 1992, Green, 1985). Seeheim's model proposes an architecture for user interfaces and applications. Its main objective is to maintain a clear separation between the software that manages the interaction and the rest of the components of the system. The model identifies three logical components (figure 1):

• Presentation component: it is responsible for managing the physical aspects of the interaction;

• Dialogue management component: it defines the structure of the dialogue between the user and the application program.

• Interface Application Model: it defines the relationships between the component that is responsible for managing the dialogue and the application.

Our extension proposes an additional division of each one of these components into a control module and a knowledge module. We will describe them in detail in section 2 of this work. Most of the UIMSs have concentrated their attention on the dialogue management component, with a lesser emphasis on the component that models the application in the interface. In practice, the latter is more difficult to model, and few UIMSs include information of this type separately from the other two components. The main difficulty in the definition of a generic application model is that its structure strongly depends on the

264 TABOADA, ET AL.

Figure 2. Integration tasks

type of application and the type of elements in charge of the communications between the interface and the application. For this reason, it is much easier to define specific models for particular application families. In this article we will concentrate on the application model proposed in MAGIT for two particular cases: the integration with a relational data base management system (RDBMS) and the integration with an expert system development tool MEDTOOL.

The tasks we have carried out during the development and implementation of the complete application are shown in figure 2: design of the applications (expert system and data base), design of the user interface, modelling of the applications in the user interface, representation of the design of the elements of the system in the specification languages of the tools and evaluation of the whole application. In particular, the most critical aspects for the acceptance of the system by the final users are the design of the interface and the evaluation.

We have performed a user interface design that is centered on the medical user. In general, a human factor based user interface is the key for the acceptance of a system (Nielsen, 1993, Beyer and Holtzblatt, 1994, Marcus and Van Dam, 1991). Our objective was to create a user interface that is consistent with the operational habits of the medical staff in order to facilitate its use and permi[ access by staff that is not familiar with computer environments (Jean, et al., 1994). During the user interface development process we distinguish between the design of the user interaction process and its representation in a formal specification language. They correspond to what Hartson et al. (Hartson, Siochi and Hix, 1990) call behavioral domain and construction domain, respectively. The behavioral domain includes the field of designing and developing the interaction part of an interface, whereas the

I N T E G R A T I N G MEDIC AL E X P E R T SYSTEMS 265

construction domain includes the development environment of the software needed for implementing the interfaces.

During the design and development, of the interaction part we have had active participation of physicians, psychologists and user task designers; and it was carried out taking into account studies on medical knowledge, conventional clinical forms and the human factors that participated, such as naturalness, functionality, ease of use and versatility (Marfn, et al, 1993). The result of this process was a set of informal specifications having to do with the definition of: the user tasks, the mechanisms for accessing the information (elements of the interface and navigation paths), and the visual appearance of the elements of the interface. During the process for the representation of the interaction, all the initial specifications of the interaction design obtained in the previous process were translated by the dialogue designer into their formal representation in MAGIT's particular specification language.

However, the a priori application of design criteria based on human factors does not automatically guarantee a good interface, or that the resulting interface is acceptable to its final users. On the contrary, once the software errors, are corrected, the next step must be the correction of the cognitive errors. It is always necessary to carry out an iterative development process so that, after successive modifications, a final product that is closer to what the user desires is obtained (Gould, Boies and Lewis, 1991, Hartson and Boehm-Davis, 1993). Thus, the initial specifications of our system were modified many times, including new considerations from the teams that participated in the project.

Even then, in order to check the real validity of the work it was necessary to perform an evaluation of the final system from the point of view of its final users. There is no general agreement on how this type of evaluation must be carried out. For example, (Holtzblatt and Beyer, 1993) consider that the use of prototypes for the evaluation of the functionality of a system hides their structure behind the details associated with the user interface. On the other hand, Ravden & Johnson (Ravden and Johnson, 1989) believe that the quantitative evaluation of the real use of the system is the appropriate path for the evaluation of its functionality and propose a practical means for carrying out the evaluation. They consider that the validity of this way of performing the evaluation is justified because the user interface is one of the main factors that influence the use of a system. We have followed the evaluation methodology by (Ravden and Johnson, 1989). As a result, we received new suggestions that led to later refinements, both of the design of the user interface and the set of functionalities offered by the underlying applications.

3. Description of the clinical domain

The objective of our work has been the design and implementation of a therapy adviser in oncology that could be easily adapted to clinical environments in hospitals located in different countries and which is aimed at real use in clinical practice (Marfn, et al, 1993). The system developed is a system for the follow up of patients in Oncology that undergo a protocol for the treatment of the so called small cell lung cancer. The protocol is made up of a set of chemotherapy and/or radiotherapy sequences that are administered for a period of time that can be as long as several years. Each therapeutical sequence of the protocol

266 TABOADA, ET AL.

specifies the chemotherapy and radiotherapy courses to follow, the duration of the courses and the temporal patterns of their administration. The drugs are usually administered in groups during the course of chemotherapy. For instance, the CAV course is made up of the combination of the drugs cyclophosphamide (CTX), adriamycin (ADM) and vincristine (VCR). After each treatment sequence of the protocol, a strategic choice is made which determines the next treatment. The general objective of the protocol is to maximize the therapeutical effects while minimizing the strong secondary effects produced by cytotoxic drugs. In order to achieve this, during each sequence a large amount of data is gathered and they permit carrying out a strict follow up of the state of the patient. Once each sequence is finished, a clinical evaluation as a function of the data collected for the patient is performed and the conclusions on the evolution or response of the disease to the treatment are obtained. As a function of the evolution of the disease, at the end of each sequence a strategic decision is made Which can modify the future course of action of the protocol, taking the most convenient alternative for the state of the patient. Figure 3 shows all the sequences of the protocol and all the strategic decisions. Finally, the protocol also describes the secondary effects that the administration of a therapy may produce. Generally, the measurement of these effects is qualitative, establishing a degree of severity of the manifestation detected in the patient. The gradation of the secondary effects will permit adapting the treatment plan established by the protocol to the state of the patient.

According to the characteristics of the clinical domain, the consultation tasks currently provided by the system are:

• Gradation of the secondary effects produced by the administration of the drugs.

• Strategic decisions on the changes of sequence in the treatment as a function of the evolution of the disease.

• Decisions on the adaptation of the treatment plan (dosages and temporal pattern of administration) as a function of the state of the patient.

4. MAGIT: Managing Graphic Interfacing Through Templates

MAGIT provides the interface designer different predefined types of windows, specifically aimed at medical environments (different types of tables, menu boxes, etc.), as shown in figure 4.

MAGIT's architecture (figure 5) seeks the same objective as Seeheim's model: to facilitate the definition of separable interfaces. MAGIT's functional modules correspond to the logic components of Seeheim's model, but we divide each one of these into two parts: knowledge and control (figure 6).

The knowledge on the visual presentation, dialogue and connection with the applications is contained in the Interaction Knowledge Base (IKB). These elements correspond to the definitions of the visual appearance, behavior and information content of each window, respectively. The presentation control in MAGIT corresponds to the Display Manager (DM). This module executes the graphic actions (defined in the IKB) on the windows. The control of the dialogue is directly implemented by the Event Manager (EM), which is a


,i /

5 7

Sequence 1: Admin is t ra t ion of three CAV courses, each four weeks long

Sequence 2: Admin is t ra t ion of three CAV courses, each four weeks long plus

brain rad io therapy

Sequence 3: Admin is t ra t ion of two DDP-VP16 courses, each four weeks long

Sequence 4: Admin is t ra t ion of three CAV courses, each four weeks long

Sequence 5: Admin is t ra t ion of two DDP-VP16 courses, each four weeks long plus

brain rad io the rapy

Sequence 6: exi t from the protocol

Sequence 7: No t reatment for three months

Sequence 8: No t reatment for two months

Figure 3. Set of sequences and strategic choices in the protocol

268 TABOADA, ET AL.

TREATMENT I~I0 I s , o N ~ , ~ , ~ o ~ Iolol I Imim ~ii'i. i~llI.

INVESTIGATIONS I ~ l I~

31 aG 13Ela~ lll~ ~. e[ ) l ~ b u

4O ~ =S.3 1 3 / I O / ~ I I I z s m , l . l ~ ~ zoo , I

EXPLANATIONS

REQUES'£ED EXPLANATIONS

OBStXVArIONS ' lal0

n V l n S TO Amrll~l ~tr~-rM~a~

~ l m u : t,~e*mx D

. . . :_ r-I

n*~tl* Q D

~ t d N a l c D

Figure 4. An example of system screen showing a summary of the most recent data of patient

simple algorithm which just applies the knowledge on the behavior of the windows stored in the IKB.

Finally, the control of the connection with the applications is implemented by the Man- agers of Communications with the Data Base (MCDB) and the Expert System (MCSE). The MCDB controls the exchange of information between the data base and the windows of the interface. The MCES manages the dialogue between the medical expert system and the interface. As we will later see, both access the IKB in order to carry out their functions and communicate with each other for transferring data between the Data Base and the Expert System.

5. Integration with the data base

In this section we will describe the application model in MAGIT for the particular case of the integration with a relational data base management system. We distinguish between knowledge about the model of the data base in the interface and communication functions. The former resides in the Interaction Knowledge Base and the latter are contained in the Manager of Communications with the Data Base (MCDB).


Display

Figure 5. Basic components in MAGIT

270 TABOADA, ET AL.

Figure 6. Relating MAGIT and Seeheim's model

5.1. Data templates

At the beginning of each clinical consultation, the first thing the physician wants to view is a summary of the set of the most recent clinical data relevant to the patient. Figure 4 displays the initial screen of the system at the beginning of a consultation. Each window of the interface is completely described in the IKB by means of a graphic template, that defines the visual appearance and behavior of its associated window, and a data template, that specifies the position in the DB of the data the window must display. The set of graphic templates describe the external features of the interface (visible objects and dialogue schemes) whereas the set of data templates define the model of the data base in the interface.

Before viewing a window (whenever it presents data from the DB) the MCDB must perform a previous search in the DB. In order to do this it accesses the data template, which will indicate (for each one of the sections of the window that show data) in which table or tables of the DB the corresponding data are stored. For instance, the window of figure 4 labeled as INVESTIGATIONS displays the data regarding three tables: hematology, biochemistry and miscellanea (figure 7 displays the data template for this window). For each table the data template must specify the clinical parameters that must be accessed. They can be of two types: parameters whose values will be presented to the user through the windows of the interface, and parameters whose values may be useful to remember because they influence the sequencing of the dialogue or may facilitate later queries to the DB. The former are defined in the field display_fields. Continuing with the example, for the hematology table, the fields that are viewed are Date, WBC (White Blood Cells), Pits (Platelets) and Hb (Hemoglobin). The parameters whose values are key for the sequencing


L • TemplateName: investigations

List of Relationships

• SectionName: scroll__table

i da t2_Locatio n i in Database

List of Tables

• Table_Name: hematology

• display fields: max(date), WBC, Pits, Hb

• dialogue_fields: rowid

conditions m

• field: patient_code

• condition: = <patient_code>

1

Figure 7. Data template for the window labeled as "INVESTIGATIONS"

of the dialogue are defined in the field dialogue_fields. In the example, the dialogue_fields are the identifiers of the row of the DB selected in each table. In the case of the table type windows these dialogue_fields are automatically associated with the rows of the table. This permits a direct association between the graphic rows and the rows of the DB, which facilitates and speeds access. For example, if the user wishes to review more information on the most recent hematology test, he can use the mouse to select the hematology row in the INVESTIGATIONS table. With this action, the user is directly selecting the identifier of the row in the data base that was previously obtained.

In addition, the data template indicates the conditions under which the query to the DB is carried out. If the conditions are in the field corresponding to a table, as is the case of the example, the MCDB performs an individual access to the table. If the conditions are in an external field, associated to a set of tables, the MCDB generates a joint call for all the tables (cartesian product). On the other hand, the condition under which a query to the DB

272 TABOADA, ET AL,

~ A15 N15 112 66 male 75416

~'~ A12 N12 129 63 male 75415

~i~ A9 N9 274 57 male 75379

A7 N7 234 48 male 75365

~,~ A3 N3 285 65 female 75254

~ A2 N2 284 58 male 75274

~. A1 N1 177 58 female 75401

A0 NO 230 65 male 77395

Figure 8. Window showing the patient table

is carried out always depends on the values of the attributes associate with the condition. These values are generally determined by the MCDB on-line. They usually come from previous accesses to the DB and are frequently stored in the templates and are indirectly selected by the user. For example, a user could select a patient for consultation from a set of patients presented in the table of figure 8. Each patient, that is, each row of the table, has a number associated to it that identifies the patient and is a key field of the DB. When the user selects a patient, it is retrieving the key associated with that patient. The MCDB will construct the query to the DB under the condition given in the data template (for example, WHERE PATIENT_CODE = <patient_code>).

5.2. Main functions of the manager of communication with the data base

In MAGIT, the communications with the applications is established through calls to the functions of the application. These, in the case of communicating with the data base, are connection functions that extract data from and introduce data in the data base. Conse- quently, in order to describe the MCDB it will be enough to describe the functions from the point of view of the user interface. That is, we must indicate which are the connection functions, the arguments they require, under which conditions we may use these functions and what effects or actions they will produce. Also, the connection functions may send messages to the interface (for example to notify errors to the user) and it will be necessary to establish in which cases this will happen and how these messages are to interpreted so that the dialogue designer establishes the appropriate interaction.

The MCDB performs two tasks. To search for data in the DB and to notify the DB of the modifications the user makes through the windows of the interface.


Data Base

Figure 9. Visualization of a window in MAGIT

5.2.1. Search for data in the DB

The process of visualizing a window that presents data from the DB is carried out in two stages, which correspond to calls to two functions: a functions of the MCDB that obtains the data from the Data Base, and a drawing function of the presentation component of the interface, that views the window on the screen.

From the viewpoint of the user interface, the search for data in the DB is carried out in the stages we show in figure 9: from the descriptions stored in the data template, a SQL preprocessor generates a SQL command in the adequate format for processing by the RDBMS. By means of this SQL command it obtains the required data from the DB, but these data are not organized in the format handled by a graphic template. The MCDB applies then a format change operation and introduces them in the data structure that stores the complete definition of the window. From this point on, the window can be viewed on the screen. If it is already displayed, it will be necessary to erase it and draw it again for it to show the possible data changes.

We must point out that the search for data is a generic function valid for any application and for any window. The function obtains all the necessary information from the declarative representation of the data template and the dialogue designer does not have to worry about the details. The only task having to do with the access to the data carried out by the dialogue designer is to fill in the data templates.

5.2.2. Data Modifications in the DB

The action of modifying data in the data base can be viewed from different perspectives. From the viewpoint of the data base, old data records can be updated, new data records introduced and previous data records erased.

274 TABOADA, ET AL.

From the view point of the user, the only action carried out is to fill in with data the appropriate sections of a window. The dialogue designer just defines in the IKB in which stages of the dialogue the user may introduce data to the windows and when the data can be sent to the data base.

The MCDB is in charge of mapping the actions carried out from one level to another. Thus, when the user inputs data through the interface windows, after the prior check for possible errors, the MCDB translates the user's action into the correct action in the DB. For this it applies a single connection function that uses the metadata defined in the data template of the window. The syntax of this function is:

modify_data_in_DB [send_error_to <error_window>]

where <error_window> indicates a window that will permit a dialogue with the user if an error occurs during the input of the data.

The first action the MCDB must carry out is to obtain the data input by the user from the data structure that defines the window. Once the data items are obtained, it arranges them in the format required by the SQL preprocessor, that is in charge of executing the operation in the DB. Prior to the modification of the DB, the MCDB must carry out a check of the type and range of the input parameters. In order to do this it will access the Data Dictionary (DD), which is a structure that contains information on the parameters used in the system. If there is an error in some data item, it will send an event to the error_window template (indicated in the modify_data_in_DB function) with an error message for the user to become aware of it. At this point the interface takes over control again, establishing some type of dialogue with the user for the correction of the error.

6. Integration with MEDTOOL

MAGIT's architecture is aimed at integrating the expert system, the data base and the user interface while maintaining the independence of the three systems; each system carries out the tasks for which it has been implemented.

Originally, the expert system development tool MEDTOOL had its own techniques for storing and administering the data it handled. However, this way of integrating data bases and expert systems does not seem to be the most attractive one in the medical domain. As the implantation of Hospital Information Systems (HIS) becomes more extended, independent prototypes based on DB-ES integration arise. Even though currently the implantation of the HIS is not very extensive, and even though the data stored in most HIS are almost exclusively used for administration tasks (van Mulligen, et al., 1993) a change of this situation in this decade is foreseeable (Collen, 1991, Ball, O'Desky and Douglas, 1991). Consequently, clinical decision support systems must be designed so that in the future they can be smoothly integrated with the HIS that are implanted. The advantages of this alternative are:

• The possibility of adapting to HIS that have already been introduced without any changes to the clinical history data bases found in the current HIS.

• The possibility of integrating specific expert systems in any other domain adapted to the needs of each department of the hospital.


For this reason, the most efficient way of introducing medical knowledge in a HIS is through small satellite expert systems, which can access the.patient data stored in data bases linked to the HIS of a hospital on-line.

6.1. General Description of MEDTOOL

The knowledge base of an expert system developed with MEDTOOL is structured into Gen- eralized Magnitudes (GM) each one of which corresponds to a clinical variable (Otero, 1991, Barreiro, et al, 1993). GMs are classified into primitive GMs and derived GMs. The values for the former are introduced by the user. The values for the latter are inferred from a knowledge module associated to each one of them. It is represented by means of a set of conditional statements of the form <assignment> [if<condition>]. Each GM is represented in memory as a sequential list organized into a three level structure, so that each GM has three indices associated to it: type, subtype and element. The type indicates if the GM is numerical or non numerical, the subtype permits grouping clinically related GMs and the element identifies it within each group. That is, each object of the knowledge base is identified by means of the subtype and each property of an object by means of the element.

The introduction of a value for a primitive GM, or the application of the knowledge module to a derived GM in a given instant produces an event that is defined by means of a triad made up by the name of the GM, the value assigned and the absolute instant of time from which this event is true. For a derived GM this instant of time is always the maximum of the times of the events referenced in the premises of the conditional statement that infers the value assigned. For a given GM there can only be a single true event in a particular instant of time. Consequently, events are located on a virtual time axis, following a total order defined by the absolute location dates. We assume that an event persists until a new event is obtained for the corresponding GM. There is a ignorance propagation mechanism which eliminates the persistence of a derived .GM if, when the knowledge is applied, any of the GMs it depends on is unknown.

The temporal knowledge representation language is based on a small set of primitives. In order to access an event we only use the constructions:

• < G M >, which accesses the last value (current value due to persistence) and

• ant (< G M >), which accesses to the value before the last.

In order to have access to the time of an event we use the operators:

• days (< event >),

• hours (< event >),

• secs (< event >),

which produce the days, hours or seconds elapsed from an arbitrary time origin. Two temporal pseudoconstants are introduced:

276 TABOADA, ET AL.

• now, which corresponds to the current instant of time

• creation, which corresponds to the instant the patient was included in the system.

The temporal model employed has a parallel with models in Physics: any decision of the system is only based on the current value and the previous value of the variables. Both values jointly define the state of the system. If it is necessary to access a remote event, we must define an auxiliary GM that maintains its value through persistence until it is needed (e.g. "minimum of hemoglobin values"), and which is updated in each consultation. The whole history of the clinical problem is thus summarized in the current state. It is an unusual style for the representation of knowledge, but it improves efficiency and preserves flexibility.

Furthermore, during the inference process, the knowledge application mechanism applies all the knowledge to the summary of the history of the patient. If a data item corresponding to a parameter is omitted for a patient, the expert system will not assign a value to that parameter, so that the ignorance of a parameter will generate ignorance over all of the parameters that could be deduced directly or indirectly from the omitted ones. Therefore, the expert system never asks the user about omitted parameters. In addition, if the expert system detects inconsistencies during the inference process, it will not be able to generate conclusions from these inconsistent data items. The user can become aware of the inconsistencies by means of the absence of conclusions and through the explanations generated. This way, the user can repeat the inference process with new data for the patient.

6.2. Manager of communications with the expert system (MCES)

The solution we have adopted for the integration with the expert system is similar to the one used for the integration with the data base. The Application Interface Model distinguishes between knowledge about the application and communication functions. The former resides in the Data Dictionary (DD) and the latter are contained in the Manager of Communications with the Expert System (MCES).

The MCES is made up functions for the input of data to the expert system in the different possible situations and the gathering of conclusions. These functions access the data contained in the DD, are those presented in figure 10 and correspond to the tasks the user may carry out with the system:

• Initialization. Before activating the expert system it is always necessary to carry out a previous initialization step which consists in:

1. Calling the expert system so that it establishes the connection, indicating the total number of patients currently included in the protocol. This function returns a boolean value of 0 if there is an error in the connection and 1 if the connection has been successful.

2. When the expert system has been initialized, the following steps are carried out for each patient:

I N T E G R A T I N G M E D I C A L E X P E R T S Y S T E M S 277

j .

| ~'~.

I I I I

% %

h"

I !

©

Figure 10. M a i n func t ions o f the M C E S

278 TABOADA, ET AL.

(A) The interconnection buffers are loaded with a summary of the data stored in the data base of the patient. This task is carried out by the function for loading the data exchange buffers (see later).

(B) The expert system is notified so that it gathers the patient data from the buffers, indicating the key that identifies it.

(C) The interconnection buffers are prepared for the transmission of another patient's summary.

Selection of the current patient : It consists in two calls to the expert system in order to:

1. Indicate the date in which the patient that is going to be selected was created.

2. Select the patient, referencing it through its identification code.

Creation of a new patient:

1. The date in which the patient is going to be created is established and the expert system is notified of the creation of a new patient with the creation date.

2. The patient is selected in the expert system by means of a call to it.

3. The initial values deduced by the expert system are gathered from the interconnection buffers and are transferred to the data base. This task is carried out by the function for gathering the data inferred by the expert system (see later).

Deletion of a patient from the expert system. It consists in:

1. Calling the expert system indicating the identification of the patient.

2. Performing a logic deletion in the data base of the patient.

Inferences of the expert system:

.

2.

The expert system is activated.

When the system finishes its inference process, the inferred data are gathered form the exchange buffers and are stored in the data base (function for gathering the data from the expert system, see later).

Loading the data exchange buffers. The exchange of data from the DB to the ES is carried out by means of two buffers, a numerical one and a non-numerical one. The data coming from the DB are identified by four arguments table_name, field_name, value, date, where the pair (table_name, field_name) identifies each parameter in the patient data base, value is the value the parameter takes and date is the date associated to the value in the format of the DB. On the other hand, the data in the ES are represented by triplets of the form parameter, value, date, where each parameter is given by another triplet type, subtype, element. The function for loading the buffers changes the format of the data before loading them into the buffers and in order to do this accesses the DB of the system.


Collection of the data inferred by the expert system. When the expert system is inferring data, it loads them in the appropriate exchange buffers. The collection of the data consists in:

1. Recovering from the buffers all the triplets of the form {parameter, value, time} for each parameter, and changing them to the format of the data base {table_name, field_name, value, date}.

2. Dividing the whole set of data recovered into subsets taking into account the way in which the data must be grouped in the database. That is, each subset will be made up of all those data that are going to be stored in a table or relation in the DB (relational in our case).

3. Grouping the data of each subset by date, as the registers of the data base are associated by dates.

4. Sending to the DB for each relationship the data registers associated with the same date.

Confirmation of advice generated by the expert system: There are some situations in which it is advisable for the user to supervise the results obtained by the system. A particular case is the therapeutic advice generated by the system (figure 11): a therapy advice may be confirmed by the user or ignored, in which case the user must indicate the expert system the therapy he will administer. This situation establishes a dialogue between the user and the expert system based on:

1. Input of starting facts by the user.

2. After the execution of knowledge, if the system has deduced some therapeutical advice, it is presented to the user, requesting confirmation. In figure 11 the user must confirm or reject the chemotherapy course made up of the drugs Cyclophosphamide, Vincristine and Adriamycin with the administration pattern indicated. If the user does not accept the drug administration advice, he will have to indicate the dosage and the temporal pattern to apply to the patient.

3. The expert system is informed of the real therapy to be administered (through the interconnection buffers), executing the knowledge again. The expert system obtains parameters related with the administration of the drugs, such as real dose administered to the patient, delay in the administration, dose accumulated by the patient, etc.

4. The inferences are collected from the buffers and are transferred to the data base by means of the data collection function.

Visualization of the recommendations deduced by the expert system. In addition to the therapeutical recommendations, the system generates other advice regarding the treatment and the toxicities produced by the treatment on the patient. The user can access these recommendations through access guides designed to this end and located to the right of figure 4. Through these guides, the user can review the conclusions he

280 TABOADA, ET AL.

PRTIEN E~SlO ~Ol~O'U~Ol~ ~1 mt l~ l "u~°NS t ~',~ la5 1.1 ~ 1 r~ , . .=~ l )~ ]~o~ ,a ~ i , . , [ ~ ] l.~,,,,=,,=,~ ~ = . t

TREATbIENT

21/10)~ ¢ic]a~pF,:~zi~% IS~ l~G 750 08~3 19~20q~ 2t/i0/92 vi~rlstine I 92oR2o 2 92022o 1920~2090

i DOYOU CON~IRM DRUGS

ADVISED BY ES?

lo/1o j~2 [ i i o ~ I ~z'~¥ i e1C1 4~

F~PLANATIONS

REQUESTED EXPLANATIONS

. . . . I ~ . ~ s E ~ u ~ v

16e os83 t 92o2~ o ~o oos$~ 7

GUID][TO A [p.'I~ TOXI f, ffl[$

~mus~o.s[~,,a~,T,o.s[ T ~ d u n t t ~ =

D w t ~ l i x D

I OBSERVAT,ONS I~10]

Figure 11. An example of system screen showing an advice from the expert system

wishes in the desired order. This way, a user guided interaction style prevails when the user accesses the expert advice. The guides remember the conclusions the user has already reviewed and confirmed, marking the dialogue boxes associated to those topics in inverse video (see the right part of figure 4).

6.3. Data Dictionary

The integration with the ES requires representing in the interface the information on the structure of the knowledge base of the expert system. No more information on the expert system is required because the communication with the expert system is very limited. The responsibility for the control of the dialogue lays with MAGIT.

We employ a Data Dictionary (DD) that establishes the equivalence between the objects of the expert system and the entities of the data base (remember that these are already related with visible parameters in the interface through the data templates and MCDB). This integration solution is similar to the one proposed by (van Mulligen, et al., 1994) in the integration of existing applications for processing data and data bases in a network. Their integration architecture contains a central data model which describes their location. On the other hand, in (Linnarsson, 1993) is defined a data dictionary that contains all the medical terms required for representing medical data in the patient data base and medical knowledge in the knowledge base.


The DD stores two types of information: MCES control data and system interaction data. The control data establish a one to one correspondence between the objects defined in the expert system and those defined in the patient DB. The attributes of the objects defined in the Knowledge Base of the expert system are identified by means of integer triads with the format {type, subtype, element}. Each one of them must correspond to some attribute defined in the DB, which is identified by a 2-tuple of the type {table_name, field_name}, where the table_name is the name of the relation that contains information on the object in the DB and the field_name is the name of the attribute.

The control data are used by the MCES in order to execute its functions in the process of initializing the system as well as during a consultation. In both cases, there is always an exchange of data between the patient DB and the expert system. The control data prevent the MCES having to know how the data are stored.

The interaction data contain information on the validation of data .(range of the data or set of possible data for a parameter), default values and units of measure of the parameters. All this information is used by the MCDB during the input of data.

The data dictionary was constructed following the relational data model of the RDBMS: it is made up of a set of tables which store, group and relate the metadata, so that for the RDBMS it is no different from a data base. Moreover, the MCES uses the dictionary in an active or dynamic way. In a passive mode, before starting the data processing, all the definitions are extracted from the data dictionary. In an active mode, there is always a connection between the MCES and the dictionary when processing some function.

7. Evaluation of the system

The evaluation carried out is based on a practical method proposed by (Ravden and Johnson, 1989). This method has been designed for evaluating the user interface of a system through a quantitative evaluation of the use of the system. For this reason, this method has been used for evaluating the whole system, both the user interface and the functionality of the system.

Following the recommendations of its authors, the evaluation was carried out by different groups of users (physicians and software engineers that had nothing to do with the development of the system) with different experiences on this type of system. The method is based on a fundamentally practical tool in the form of a checklist. This list contains a set of questions or criteria derived from studies based on human factors, which permit the evaluation of the use of a system and the identification of its problem areas. This method may be applied before, after or during the construction of the system. We have used it for evaluating the first final prototype of the system, checking its validity as well as extracting and improving the most negative aspects of the system in future versions.

The checklist employed is made up of eight sections, each one of which is associated with a criterium derived from ergonomic studies: visual clearness, consistency of the system with the expectations from the user, compatibility with the user working environment, clear functionality, transparency, appropriate functionality, flexibility and error prevention and control. In addition, each section is divided into three main parts:

282 TABOADA, ET AL.

A heading, which describes the criterium that is evaluated in the section.

A set of questions, which permit quantifying the criterium. The questions may be evaluated with a grade from 0 to 10, and each question may be accompanied by a comment regarding the criterium. The comments are very useful when determining the deficiencies of a system.

A global question on the criterium to be evaluated.

This list is an adaptation of the original proposal by (Ravden and Johson, 1989), excluding or modifying some questions that make no sense in our case.

The stages we have followed during the evaluation of the system are:

Prepare the evaluation tasks: The tasks we have chosen in order to carry out the evaluation attempt to include all the functionalities of the system. They simulate a real consultation with a patient included in the protocol. Before the evaluation we have introduced the data corresponding to several consultations, which define the previous clinical history of the patient. The tasks to be carried out by each evaluator are:

1. Access the patient data corresponding to previous consultations.

2. Introduce new data associated with the current consultation.

3. Activate the expert system.

4. Visualize and confirm the treatment conclusions obtained by the expert system.

5. Visualize the conclusions on the toxicities derived from the treatment.

Even though the tasks we mention were preset, the medical evaluators were interested in performing some additional ones, such as the creation of a new patient, the simulation of more consultations . . . . In addition, the evaluators have not always followed the established order in a strict manner.

Inform the evaluators of how the system works and of the evaluation context: Theoret- ically, before the evaluator carries out the tasks, he must be clearly informed on how the system works and on how the evaluation is going to be carried out. It is important to explain to them why the evaluation is carried out, and why their collaboration has been requested, in what way their criteria of the system is going to benefit it, what the evaluation procedure is, etc. In most cases this stage has been reduced to a minimum, as our experience proves that evaluators are generally impatient when learning about a system, and prefer to find out the details of the way the system works as they interact with it.

Analysis of the results: Following the evaluation method proposed by (Ravden and Johnson, 1989) the main source of information for the evaluation comes from using the checklist. The interpretation of the results of this list is a difficult task. The answers obtained depend mainly on the experience the evaluator has in working with similar systems. The results obtained are shown in table 1. The analysis of the checklist allowed us to detect the acceptable aspects and the main problem areas of the system; in addition, it indicated how


Table 1. Result obtained from the evaluation of the system

Sections Physicians Software Engineers

Visual Clearness 8.3 7.5 Consistency 9.2 7.8 Compatibility 8.2 8.1 Clear Functionality 7.8 7 Transparency 8. l 7.5 Appropriate Functionality 8 7 Flexibility and Control 8.9 8 Prevention and Error Control 8 7.4

to improve them and how to modify the system in order to adapt it as much as possible to the way the user expects to work with it. Of more interest were the comments made by the users during the evaluation process which, although they only provide information on the subjective acceptance degree, refer to specific details of the interaction, and this permits improving the system. In general, the way the information is grouped, ordered and accesses has been valued by the medical staff. Some specific suggestions were the following: 1) it is positive for the data to be introduced by conceptual units associated with the windows and that the user can choose windows in an undefined order; 2) It would be good to define windows that act as a guide during the data introduction and viewing process (the user of the expert system handles large amounts of data) 3) the use of help messages for handling the system and alarm messages when important data is produced or when values that are far from normality are detected would make the use of the system easier.

8. Conclusions

In this work ,we have presented a tool aimed at the development of clinical information systems with embedded modules and we have described a system designed with this tool. Globally, the system consists of three tools that are integrated, based on a homogeneous approach: the differentiation between knowledge and control. The control part does not change from one application to the next, eliminating the need for programming during the system development process. This way, the development and implementation of an intelligent information system in a specific domain (oncology) requires three well differentiated tasks:

• fill in the knowledge base of MEDTOOL with medical knowledge from the domain.

• fill in MAGIT's knowledge base with knowledge on the man-machine interaction process (visual appearance, information content and dialogue).

• generate the data base and a data dictionary which stores the mapping between the objects of the data base and the objects handled by the expert system.

284 TABOADA, ET AL.

One of the main contributions of the solution described is the introduction of a declarative representation of the user interface. This representation is complete, including the specification of the visual appearance of the windows, their behavior and their links to the data base. In particular, the behavior of the windows, that is, the dialogue sequences, may be described in a precise manner, hiding the details of the internal representation. The design of the interface is performed at a higher level of specification than with the use of conventional interface programming techniques. The main advantages associated with the use of a declarative representation of the association with the data base are modularity, possibility of incremental declaration and ease of maintenance. In addition, the system improves the productivity of interfaces as it permits designing different versions of an interface in a rapid manner. A particular version adapted to the habits of a hospital (regarding forms, information contents ..... ) may be easily obtained without any need of changing the internal application (same DB and same ES), and without any need for "reintegrating" the applications (the integration has already been performed in the tool itself).

In this work we have presented a particular application corresponding to a system for producing therapy advise in Oncology. A simple and consistent interface has been designed that allows the users to access on-line help during the process of computerizing clinical histories and completing therapy orders. In addition, the user may access advice on the treatment of the patient and on the degree of toxicity in the patient through some access guides designed to this end. These guides permit reviewing the advice generated by the expert system in the order the user desires, favoring a user guided interaction style and not that imposed by the system. Furthermore, these guides remember the advice the user has already reviewed and confirmed marking the topics in inverse video. There are other styles for interacting with the expert system that also avoid the imperative dialogue style of conventional expert systems. In this line, the interaction based on critique would be an alternative to the interaction based on advice guides we propose here. With our solution the interaction with the system is less disruptive.

MAGIT is implemented in Franz's Allegro Common Lisp and Common Windows, the expert system TAO/MEDTOOL is implemented with Medtool, a Medical ES development tool, and both are integrated with an Oracle relational database. In the near future we are going to translate the implementation of the tool to C++ and the visual presentation functions to the Motif environment in order to use more standard software support. These functions are currently supported in Allegro Common Lisp and Common Windows.

Acknowledgments

This work has been supported in part by grant TIC-95-0604 from the CYCIT, by grant XUGA-20603A95 from Xunta de Galicia and by grant PCT-94-48 from Comunidad Aut6noma de Murcia.

References


Arkad, K., Ahlfeldt, H., Gao, X., Shahsavar, N., Wigertz, O., Jean, E & Degoulet, P. (1994). Integration of data driven decision support into the HELIOS environment, International Journal of Bio-Medical Computing, 34, 195-205.

Autio, K., Kari A. & Tikka, H. (1991). Integration of knowledge-based system and database for identification of disturbances in fluid and electrolyte balance, Computer Methods and Programs in Biomedicine, 34, 201-209.

Ball, M., O'Desky, R. & Douglas, J. (1991). Status and progress of Hospital Information Systems (HIS), Interna- tional Journal of Biomedical Computing, 29, 161-168.

Barreiro, A., Otero, R.R, Matin, R. & Mira, J. (1993). A modular knowledge base for the follow-up of clinical protocols, Methods of Information in Medicine, 32, 373-381.

Berman, L., Cullen, M. & Miller, E (1993). Automated Integration of External Databases: A Knowledge-Based Approach to enhancing Rule-Based Expert Systems, Computers and Biomedical Research, 26, 230-241.

Beyer, H. & Holtzblatt, K, (1994). Calling down the lightning. Tools, techniques and concepts to optimize user interfaces, IEEE Software, 11(5), 106-107-113.

Collen, M. (1991). A brief historical overview of Hospital Information Systems (HIS) evolution in the United States, International Journal of Biomedical Computing, 29, 169-189.

Edmonds, E. (1992). The emergence of the separable user interface. In E. Edmonds (Ed.), The Separable User Interface. London: Academic Press.

Gould, J., Boies, J. & and Lewis, C. (1991). Making usable, useful productivity. Enhancing computer applications, Communications of the ACM, 34(1), 74- 85.

Green, M. (1985). Report on Dialogue Specification Tools. In Pfaff (Ed.), User Interface Management Systems. Berlin: Springer Verlag.

Hartson, H. & Boehm-Davis, D. (1993). User interface development processes and methodologies, Behavior & Information Technology, 12(2), 98-114.

Hartson, H., Siochi, A. & Hix, D. (1990). The UAN: A user-oriented representation for direct manipulation interface designs, ACM Transactions on Information Systems, 8, 181-203.

Holtzblatt, K. & Beyer, H. (1993). Making customer-centered design work for teams," Communications of the ACM, 36(10), 93-103.

Jean, E, Lavril, M., Lemaitre, D., Sauquet, D. & Degoulet, R (1994). A software engineering approach for medical workstation development, International Journal of Bio-Medical Computing, 34, 249-260.

Linnarsson, R. (1993). Decision support for drug prescription integrated with computer-based patient records in primary care, Med. Inform., 18(2), 131- 142.

Marcus, A. & Van Dam, A. (1991). User interface developments for the nineties, Computer, 24(9), 49-57. Matin, R., Taboada, M., Mira, J., Barreiro, A. & Otero, R.R (1993). Design and integration of a Graphic Interface

for an Expert System in Oncology, International Journal of Bio-Medical Computing, 33(1), 25-43. Marin, R., Taboada, M., Mourino, G., Sofia, E, Mira, J. & Delgado, A, (1992). Asynchronous dialogue control

in a medical graphic interface, Cybernetics and Systems: an International Journal, 23(3-4), 271-284. van Mulligen, E., Timmers, T., Brand, J., Cornet, R., van den Heuvel, E, Kalshoven, M. & van Bemmel, J. (1994).

HERMES: a health care workstation integration architecture, International Journal of B io-Medical Computing, 34, 267-275.

van Mulligan, E., Timmers, T., van der Heuvel, F. & van Bemmel, J. (1993). A prototype integrated medical workstation environment, Computer Methods and Programs in Biomedicine, 39, 333-341.

Nielsen, J. (1993). Iterative user interface design, Computer, 26(11), 32-41. Otero,R.R (1991). MEDTOOL: Una herramienta para el desarrollo de sistemas expertos, Unpublising Thesis,

Universidad de Santiago, Spain, 1991. Patil, R., Silve, J. & Swartout, W. (1994). An architecture for a health care provider's workstation, International

Journal of Bio-Medical Computing, 34, 285-299. Ravden, S. & Johnson, G. (1989). Evaluating usability of human- computer interfaces: a practical method,

Chichester: Ellis Horwood Ltd. Taboada, M., Matin, R., Mira, J. & Macfa, M. (1996). Representation of Human-Computer interaction by means

of Behavior Rules, Applied Artificial Intelligent: An International Journal, 10, 163-185. Thomas, I. & Nejmeh, B. (1992). Definitions of Tool Integration for environments, IEEE Software, 9(2), 29-35.

Integrating medical expert systems, patient data-bases and user interfaces

Documents

Transcript of Integrating medical expert systems, patient data-bases and user interfaces