a development environment for knowledge-based medical applications on the world-wide web

Artificial Intelligence in Medicine 14 (1998) 279–293

A development environment for knowledge-basedmedical applications on the world-wide web

A. Riva a,*, R. Bellazzi b, G. Lanzola b, M. Stefanelli b

a Laboratorio di Informatica Medica, IRCCS Policlinico S. Matteo, Pa6ia, Italyb Dipartimento di Informatica e Sistemistica, Uni6ersita di Pa6ia, Pa6ia, Italy

Received 14 January 1998; received in revised form 30 March 1998; accepted 15 April 1998

Abstract

The World-Wide Web (WWW) is increasingly being used as a platform to developdistributed applications, particularly in contexts, such as medical ones, where high usabilityand availability are required. In this paper we propose a methodology for the developmentof knowledge-based medical applications on the web, based on the use of an explicit domainontology to automatically generate parts of the system. We describe a development environ-ment, centred on the LISPWEB Common Lisp HTTP server, that supports this methodol-ogy, and we show how it facilitates the creation of complex web-based applications, byovercoming the limitations that normally affect the adequacy of the web for this purpose.Finally, we present an outline of a system for the management of diabetic patients built usingthe LISPWEB environment. © 1998 Elsevier Science B.V. All rights reserved.

Keywords: Web-based applications; Knowledge-based systems; Insulin-dependent diabetesmellitus

* Corresponding author.

0933-3657/98/$ - see front matter © 1998 Elsevier Science B.V. All rights reserved.

PII S0933-3657(98)00038-4

A. Ri6a et al. / Artificial Intelligence in Medicine 14 (1998) 279–293280

1. Introduction

The World-Wide Web (WWW) environment offers a set of features that can beextremely useful in the design of a distributed application: the use of the hypertextdata structure as a high-level representation of the available resources makes it easyfor the user to access them without the need to be aware of their physical location;the underlying communication protocol is simple and extremely flexible; powerful,standard and easy to use client software is available under the form of webbrowsers, whose multimedia capabilities allow the users to easily access knowledgeand information stored under different forms in different locations. These charac-teristics are particularly useful when the application is to be integrated in a hospitalinformation system, a context that is characterized by the presence of severaldistributed and heterogeneous sources of information that must be accessed in auniform way by unskilled users. The first experiences in the use of the WWWenvironment in a medical context have exploited these features to provide afriendly, powerful and consistent interface to traditional hospital informationsystems. Examples of applications include information sharing [1], clinical querymanagement [4] and application development [3] in a medical environment.

In this paper we describe a software development environment to create web-ac-cessible, distributed applications consisting of four main components: an explicitrepresentation of the domain ontology, a set of inference engines, a long-term datarepository, and a graphical user interface. Moreover, we will show how the dataacquisition task may be conveniently performed in this context. The developmentenvironment we are going to describe is based on LISPWEB, a Common LispHTTP server able to dynamically generate HTML pages, and to handle customizedextensions of the hypertext transfer protocol (HTTP). By combining the power andflexibility of LISPWEB with the services offered by external agents (e.g. databases,data analysis tools), it is possible to develop complex knowledge-based medicalapplications, relying on the WWW architecture in order to achieve the usability andavailability qualities that are recognized as essential for the success of an AIapplication in medicine [9].

2. Web-based application development

The WWW is rapidly becoming the ideal platform for the development ofdistributed applications. As mentioned in the previous section, the main reasons forthis are the high availability of powerful, standard client software, and thesimplicity of the underlying communication protocol, the HTTP. However, theWWW was originally conceived simply as a document distribution infrastructure,and attempts to use it for different purposes must cope with difficulties that increasewith the complexity of the application.

The normal, common usage of the WWW is in itself an example of a distributedinteractive application. In this case, the goal of the application is to enable the userto access on-line documents and to follow the hyperlinks they contain just by

A. Ri6a et al. / Artificial Intelligence in Medicine 14 (1998) 279–293 281

clicking on particular areas of the document text with a web browser. Thisinteraction model has been augmented with the ability to fill in and submit formsand to associate a uniform resource locator (URL) to a program, residing on theserver, that is run whenever that URL is requested. The protocol used to run theprogram, pass the request parameters to it and receive the reply is called commongateway interface (CGI) and is at the base of the vast majority of web-basedapplications today.

Although adequate for most simple applications, the CGI approach suffers froma number of drawbacks whose severity increases with the size and complexity of theapplication to be developed [7]. CGI is inherently modeled on the statelessparadigm of the WWW; that is, the server has no memory of the previous actionsof the client. Therefore, the result of a request cannot depend on the result of theprevious requests. Moreover, the CGI approach requires launching an externalprocess to handle each request, something that can be quite slow, and that imposeslimitations on the amount of information that can be exchanged between the serverand the external process.

The natural solution to this problem is to develop extended, special-purpose webservers, that make it possible to create more ‘intelligent’ applications while remain-ing in the context of a web-based system. The most important possible directions ofevolution include: developing an alternative to CGI for faster program invocation;overcoming the stateless nature of HTTP transactions, extending the HTTP proto-col to support more complex forms of interaction between client and server. Forexample, one of the most needed features is the ability to communicate with adatabase. Instead of relying on CGI for this purpose, one may extend the webserver with functions to store values and perform queries, thereby making thedatabase accessible on the WWW in an efficient and straightforward way. Anexample of this approach is Oracle Web Server, an HTTP server that providesfacilities to communicate with a relational database and to generate HTML pagesusing data extracted from the database.

Our approach represents a further step in this direction: the use of the LISPWEBserver allows the web-based application to exploit the full power of a high levelprogramming language, as well as any number of external services through thenetwork communication facilities that it provides. Applications built using LISP-WEB have full control over the HTTP transactions that take place between theserver and the web browser, and at the same time can exploit a high-level languagewith powerful abstraction capabilities to generate HTML pages; moreover, it iseasy to integrate legacy applications written in Common Lisp, and to make themaccessible on the WWW.

3. The LISPWEB development environment

For the purposes of our discussion, we will consider a typical knowledge-basedapplication as composed of the following parts:


� A knowledge base, consisting of a structured description of the ontology of thedomain under consideration, and of a long-term data storage.

� A reasoning engine, that manipulates the objects contained in the knowledgebase.

� A user interface, providing data acquisition and presentation functionalities.In the next sections, we will briefly describe the LISPWEB development environ-ment, and we will show how it allows large parts of the system to be automati-cally generated from appropriate information added to the system’s knowledgebase.

3.1. The LISPWEB HTTP ser6er

LISPWEB is a Common Lisp development environment for distributed applica-tions over the WWW [10]. It consists of two main modules: an HTTP server anda library of functions to create HTML pages. The HTTP server handles all thestandard HTTP methods (GET, POST, etc.), performs IP-based and password-based access control, provides request logging and timing, serves standard HTMLpages, images, Java applets and generic binary files. Thanks to its object-orientednature, it is fully configurable and extensible: for example, users can easily definenew methods; specialize the response function for particular classes of requests, orcustomize the request logging function. The server is also able to act as a TCPclient; it can therefore communicate with other servers in a distributed computingenvironment (databases, mail servers, etc.) using an ad-hoc extension of theHTTP protocol.

The second component of LISPWEB is a set of tools to dynamically createHTML pages. Pages are defined using a syntax similar to the one used to defineLisp functions, and are internally represented as Lisp functions; such functionscan then be associated with a specific URL, and are run by the server wheneverthe corresponding URL is requested. The functions, that can take arguments andaccess global variables defined in the Lisp environment, are responsible for gener-ating the HTML code that will be sent to the client.

The developer is provided with a library of HTML-producing Lisp functions,that range from simple tag insertion functions to high-level formatters able toproduce large blocks of HTML code. For example, the list-to-table function takesa list of lists (lists are a primitive data type in Lisp) and produces an HTML tablewhose rows are the sub-lists of the input list. Optional arguments can be used tospecify additional features of the table, such as border width, cell alignment, andso on. This tool is especially useful when the input list is not known a priori, sothat a manual generation of the HTML code would be impossible. Moreover,new functions can be defined to generate frequently used code fragments (e.g.page banners), thus avoiding unnecessary and time consuming repetitions on partof the developer. Finally, this approach guarantees that the resulting HTML codewill always be syntactically correct and compliant with stylistic recommendations.

Other functions allow the values of the HTTP header fields, and of the formfields in the case of a POSTrequest, to be examined and possibly modified. This


eliminates the need for external CGI scripts, since the same Lisp function canaccess the field values and generate the appropriate response page.

Finally, LISPWEB is able to support extensions of the HTTP protocol. Inparticular, we have defined a protocol called STSP, designed to allow a bi-direc-tional exchange of information between two agents. While the HTTP protocol isoriented toward the exchange of request–response messages typical of client–server architectures, the STSP protocol makes it possible to perform more com-plex forms of negotiation and dialogue between agents.

3.2. The domain ontology

An explicit, shared domain ontology is recognized as being a basic componentof any large AI system [6]. Although, strictly speaking, the ontology is a knowl-edge-level concept, in a real-world system it needs to be represented by some kindof data structure. In the following, we will deal primarily with the actual represen-tation of the ontology, after making a few assumptions on its properties.

An ontology is usually represented using objects (also called units, or frames),data structures characterized by a set of slots able to hold information. Objectscan be used to represent abstract definitions of entities (classes), or particularreal-world entities (instances). Objects can be connected by links that express thedifferent relationships between them. The is–a link between two objects, inparticular, specifies that the first one represents a subclass of the class representedby the second one, and can therefore be used to build taxonomies of objects.Normally, slots are inherited along is–a relations; that is, the set of slots of asubclass is the union of the slots of its father classes, and of its own slots.Another kind of relationship is expressed by the slot–value link, that indicatesthat the value of a slot is an instance of another class.

We will not deal here with the exact internal structure of the objects or of theslots, nor with other possible relationships among the objects. For our purposes,we need the knowledge representation system to have at least the followingfeatures:� multiple inheritance: a class should be allowed to have more than one superclass.� typed slots: it should be possible to specify the type of the values that can be

assigned to a slot.Since slots are typed, we also need to define a hierarchy of classes representingtypes. For example, we might define the class of numerical values, of string values,of fixed-length-string values, and so on. Types are abstract classes: no instances willbe created from them, but they are used to store information needed by the instanceslots.

In the case of a distributed system, the existence of a global, shared ontology isessential to ensure the possibility of communication between the architecturecomponents: the ontology acts as a common terminology to which all the agentsrefer when exchanging information. The system is therefore able to make theontology accessible to external agents through STSP calls, that provide the namesand types of the object slots, as well as the relationships among objects.


3.3. Long-term storage

Although instances in a knowledge base are meant to represent the actual objectsthat the system is manipulating, this approach is not always the most convenient orefficient. For example, blood glucose measurements taken from the daily monitor-ing of a diabetic patient can be represented by a class like the one shown in Fig. 1.However, blood glucose measurements can amount to several thousands perpatient, and creating an instance of the above class for each one is usuallyimpractical. Instead, we suppose that a relational database is used for the long-termstorage of the objects. In other words, we use the knowledge base mainly as adeclarative tool, to describe the domain ontology, while we exploit well-establisheddatabase technology in the fields of efficient memory usage and query optimizationto manage the actual data.

The problem is, therefore, how to map a set of classes in the knowledge base toa relational structure. To this aim we add a class called DB– OBJECT, with two slotscalled TABLE– NAMEand TABLE– FIELDS , to the knowledge base. This class isadded to the superclasses of each class whose instances should be stored in thedatabase; the two slots thus inherited are used to indicate the name of thecorresponding table in the database, and the list of slots that must become the fieldsof the table.

The development environment then provides functions to automatically performthe following operations:� Create a table in the database given the class name. The table name and fields

are taken from the slots inherited from the DB– OBJECTclass, while the fieldtypes are determined from the types of the slots.

� Store an instance as a record in the appropriate table. This function performs an‘insert’ operation using the values of the slots of the instance, into the tableassociated with the class to which the instance belongs.

� Retrieve one or more instances from the database. This function performs aquery on a database table, and creates one instance of the corresponding classfor each row in the query result.The system uses type information in order to determine the relational structure of

the database. If an object contains a slot called ID, the value of that slot is takento be a unique identifier for the instances, and the corresponding field is defined asa primary key for the database table. Moreover, sometimes the type of a slot maybe defined in terms of another class. In this case, when creating the table for thefirst class, the type of the slot will be the type of the ID slot in the second one. For

Fig. 1. The structure of the BGL– MEASUREMENTunit.


Fig. 2. Mapping a slot–value relationship on a relational model.

example, the value of the PHYSICIAN field in the PATIENTS class should be aninstance of the PHYSICIANS class (representing the physician that is currentlyfollowing the patient under consideration). When mapping this structure to a table,the type of the PHYSICIAN field in the PATIENTS table is set to the type of the IDfield in the PHYSICIANS table. This situation is handled recursively by the abovedescribed functions, so that, for example, when retrieving an instance of thePATIENTS class from the database, the associated instance of the PHYSICIANSunit will also be retrieved, and the link between the two will be re-established (seeFig. 2).

One of the reasons for recreating instances from the database contents is that theknowledge representation tools often provide automated reasoning facilities tooperate on them. For example, in a rule system the firing conditions for the rulescould be expressed in terms of the values of particular slots of the objects in theknowledge base. Therefore, before using a rule system such as the one justdescribed, it is necessary to ‘prepare’ the knowledge base by creating all theinstances that are needed in order to run the rules. Usually, the effect of the ruleswill be to alter the contents of some slots in one or more instances; the changedinstances will hence be saved back to the database at the end of the process.3.4. Data acquisition

Since the user interface is web-based, information acquisition is performed usingHTML forms, that are dynamically generated by the system. In particular, thesystem is able to generate an HTML form that allows the user to create a newinstance of a given class, by supplying the needed slot values. In order to performthis task, the system must determine:


� Which slots of the class should appear in the form.� Where they should be positioned on the HTML page.� How they should be rendered using HTML elements.We follow here the same approach that was used for the definition of the databasetables. We add to the knowledge base a special-purpose class, called HTML– OB-JECT, from which the other classes inherit three slots, called FORM– SLOTS,FORM– LAYOUT, and OUTPUT– LAYOUT, respectively. The value of the first one isthe list of the slots to display in the form, while the value of the second one shouldbe the name of a function that takes as input the object to display, and returns theappropriate HTML code. This is done in two steps:� For each slot that must appear in the form, invoke a generic function that

determines how to render it in HTML. This can be done basing only on thename and type of the slot. For example, string and numerical values can be inputusing text fields, boolean values can be represented with checkboxes, and fieldsthat take a set of objects as their possible value can be rendered as radio buttons,menus or multiple-choice lists.

� Once all the HTML fragments for the slots have been generated, determine howto lay them out on the page. The user can resort to one of several predefinedlayout functions (e.g. a simple list of fields) or define a class-specific one.

The meaning of the OUTPUT– LAYOUTslot will be explained below.HTML forms are very simple to create and use, but have a number of

limitations. The most important one is that they don’t provide any form of inputvalidation before the form contents are submitted to the server. For example, asingle input field is used for text and numerical values, and there is no way to checkthat what the user inserted is actually a number when a number was required. Apossible solution to this problem is the use of client-side scripting languages such asJAVASCRIPT. JAVASCRIPT, developed by Netscape Communications, is aC-like language that can be embedded in HTML pages, using an ad hoc set ofextensions to the HTML language. In particular it is possible to specifyJAVASCRIPT functions to be run whenever the contents of a form field arechanged, or before submitting the entire form. We have therefore defined a libraryof JAVASCRIPT functions able to determine whether the value entered in a formfield belongs to the appropriate type. The functions are stored in a slot of the classthat represents the type, and are automatically added to the HTML code in orderto enforce client-side type checking when generating the form.

We will now show an example of how the system is able to generate a formthrough which the user can create an instance of a class, and a page thatsubsequently shows the contents of the instance. We refer again to the BGL– MEA-SUREMENTclass shown in Fig. 1, but we now suppose that the type of theBGL– VALUEslot is POSITIVE – NUMBER, a subclass of the number class. For eachone of the three slots, the system generates a text field with a differentJAVASCRIPT validation function. For example, the text field to input the value ofthe BGL– VALUEslot would be defined as follows:


Binput name=‘‘bgl – value’’

onchange=‘‘larger – than(this.value, 0)’’ \

where LARGER– THANis a JAVASCRIPT function that checks whether the valueinserted in the field is larger than its second argument, and signals an error if not.The function is automatically included in the HTML page being generated, alongwith those needed by the other elements of the form. Once all the input elements forthe class slots have been generated, they are passed to the function that is the valueof the FORM– LAYOUTslot of the class. The result of this function is the HTMLcode that displays the input fields within the form (see Fig. 3). Note also that in thiscase the slot names are links that point to documentation about the meaning of theslot and its possible values.

When, after filling in the form values, the user presses the ‘create’ button, theform contents are sent back to the server that runs the function specified in theACTION attribute of the form. This function receives as input the class name, andthe values inserted by the user; using this information, it is able to create aninstance of the specified class in the knowledge base and to assign the correct valuesto its slots. Note that the function is totally generic, since all the informationneeded for this purpose is contained in the class slots.

3.5. Output presentation

The generation of HTML pages to display the contents of particular objects isvery similar to the process described in the previous section. The only difference isthat in this case, for each slot, an HTML fragment that displays its value is needed,rather than the one to generate a form element. Therefore the OUTPUT– LAYOUTfunction first applies to each slot a generic function that produces the desiredHTML expression, basing on the type of the slot and, optionally, on stylisticconstraints set by the developer; next, it applies one of several possible layoutfunctions to the set of HTML fragments in order to lay them out on the page. Fig.

Fig. 3. An automatically generated HTML form to acquire the values of the slots of an object.


Fig. 4. An automatically generated view of an instance of the BGL– MEASUREMENTclass.

4 shows the result of this process when applied to the instance created using theform in Fig. 3.

4. The T-IDDM medical unit

The above discussed methodology has been applied to the design and imple-mentation of a distributed system for the management of patients affected byInsulin-Dependent Diabetes Mellitus (IDDM).

IDDM is a major chronic disease in developed countries. It affects glucosemetabolism, leading to metabolic instability, hypo- and hyper-glycemia, and in-validating long-term complications. Diabetes therapy aims at controlling the pa-tients blood glucose level (BGL) through insulin injections and a strict control ofthe diet and physical exercise. The therapy is usually carried out by the patientfollowing a treatment protocol and a set of adjustment rules supplied by thephysician.

The system we are developing within the EU-funded project T-IDDM (Telem-atic management of Insulin Dependent Diabetes Mellitus) aims at providingdecision-support to both patients and physicians in handling IDDM. The archi-tecture of the system is therefore based on the integration between a patient unit(PU) and a medical unit (MU), each of which provides a set of services to itsusers [2].

The MU has been developed following the steps described in the previoussections, and includes the following components:� An explicit description of the domain ontology provided by an ontology ser6er.� A long-term data repository managed by a data-base ser6er.� A reasoning engine based on a distributed intelligent data-analysis service and on

a rule-based inference ser6ice.� A data and knowledge acquisition module.We will now describe the most important features of each component, as imple-mented in the current system prototype. It should be easy to see how, using thedevelopment environment described in the previous section, we were able toautomatically generate a large part of the system, with great advantages from thepoints of view of development time and costs, reliability, and software reusability.


4.1. Domain ontology

The ontology of IDDM, represented using a frame system, is organized intotaxonomies that describe entities (e.g. patients, laboratory values, etc.), events (e.g.BGL measurements), abstractions (e.g. hyperglycemia), drugs, diseases, therapeuticprotocols, etc. This information is made available by LISPWEB to all the othercomponents of the system, and is used to determine the behavior of the wholesystem.

4.2. Long-term data repository

The database server is used for the long-term storage of all the system informa-tion. This includes:� Patient data (both anagraphical and clinical data).� Administrative information (e.g. the names and passwords of authorized users).� Temporary information (e.g. results of previous analyses and abstractions).As previously mentioned, the structure of the data-base tables, as well as thecommands to store and retrieve the data, are generated automatically on the basisof the information contained in the knowledge base. In the current prototype of thesystem, the actual communication between LISPWEB and the relational database isensured by a specialized SQL interface, able to receive the queries to perform overthe network and to return the resulting data. However, this methodology could alsobe used by systems that employ different database connectivity tools (e.g. ODBC).

4.3. The reasoning engine

The automated reasoning functionalities provided by the system are the result ofthe cooperation between several components (e.g. the database, a temporal abstrac-tions server, a model simulation service, etc.). Here, we will describe two servicesthat are currently implemented within the T-IDDM prototype: a data analysisservice and a rule-based inference service.

4.3.1. Data analysis ser6iceAlthough the data set coming from diabetic patients home monitoring is usually

quite large, the information quality can be rather low. Diabetic patients measureand record their blood glucose level, as well as other physiological parameters,several times a day. Such measurements are often carried out in uncontrolledenvironments, are incomplete, and some of them are qualitative in nature. The datamust therefore be carefully analyzed in order to extract high-level informationsuitable for the subsequent reasoning process. This analysis is performed at the MUlevel combining statistical analysis with temporal abstractions. To this aim, we havedeveloped a temporal abstractions ser6er [5]. The result of a temporal abstraction isa time interval inside which a specified condition is true on the data underexamination. Temporal abstractions are used to derive the univariate and multivari-ate patterns that are useful to highlight the relevant features of the patientsmetabolic control.


The server receives STSP requests specifying the type of temporal abstractionto perform, the abstraction parameters and the data; the response is a list ofintervals, defined by their start and end times. The system is able to performdifferent types of temporal abstractions, whose characteristics are specified bycorresponding entities in the knowledge base. Temporal abstraction results arethen processed by LISPWEB and provided as inputs to a rule-based inferenceservice.

4.3.2. The rule-based inference ser6iceOne of the main functionalities of the MU is the ability to provide the

physician with advice on the protocol revision task [8]. This is done by anautomated reasoning process that involves the following steps:1. The current state of the patient is analyzed using a variety of data analysis

techniques. The result of the analysis is a set of problems that can be iden-tified in the patients state (e.g. a high probability of hyperglycemia at break-fast time).

2. Using a combination of model-based and heuristic techniques, the systemgenerates a set of suggestions, that is, possible adjustments to the therapeuticprotocol the patient is following, meant to solve the problems detected.

3. The system performs a search in the space of known protocols looking forone or more alternative protocols able to satisfy the suggestions generated inthe previous step. The alternative protocols are then ranked in order tominimize the changes with respect to the current one, and are submitted tothe physician for approval.

The various steps of the reasoning process are performed by appropriate sets ofrules, that are activated in succession whenever the physician invokes the deci-sion support system. The rule system is implemented within LISPWEB and istightly integrated with the frame system used to represent the domain ontology.The functions described in Section 3.3 can therefore be used to create the knowl-edge base objects needed by the rule system.

4.4. Data acquisition and presentation

As previously mentioned, LISPWEB allows all the systems functionalities tobe accessed using a standard web browser. In the current version of the system,user interaction therefore takes place in the WWW environment: all the informa-tion that must be presented to the user is converted into HTML, and user inputis received using links or forms as described in Section 3.4 and Section 3.5. Fig.5 shows an example of how different presentation formats can be combined inorder to visualize data in an effective way. In particular, the same data-set isdisplayed both in graphical form, using a JAVA applet, and as a dynamicallygenerated table. It is interesting to note that the two representations whereautomatically generated from the same data-set, just by changing the defaultpresentation style.


Fig. 5. Monitoring data visualization: plots and multicolumn tables are automatically generated byLISPWEB.


5. Conclusions

The WWW environment presents a set of features that make it very appealing asa platform for the development of distributed, interactive applications. It offerslow-cost, powerful and widely available client software, a simple and extensiblecommunication protocol, multimedia and hypertext capabilities. In order to exploitits full potentialities, however, it is necessary to extend the capabilities of webservers beyond simple document distribution.

In this paper, we have described a development environment for web-accessibleapplications, based on a Common Lisp HTTP server. The server is able todynamically generate HTML pages, and to communicate with external agents in adistributed environment through an extension of the HTTP protocol. The environ-ment supports a methodology for the development of knowledge-based applicationsthat is particularly well-suited for applications in the medical field. The methodol-ogy is based on the existence of global, shared domain ontology, used to automat-ically generate large parts of the system, as well as to make the communicationbetween the various components of the system possible. The distributed nature ofthe systems built using LISPWEB makes it easy to combine different tools andservices in a coherent system; the programmer is therefore encouraged to choose the‘right tool for the job’ (e.g. JAVA for the user interface, Common Lisp for theknowledge representation and the reasoning modules, etc.), with large gains interms of efficiency, ease of development, and reusability of legacy software.

Our development environment is currently being used to realize the MU of theT-IDDM project for the distributed management of diabetic patients. This experi-ence has demonstrated the power and flexibility of the LISPWEB environment inproviding the system with a high usability and availability, as well as its ability toovercome the limitations normally associated with the WWW paradigm. It istherefore possible to develop a prototype application very quickly, and to make itaccessible to a large number of unskilled users, through a simple and uniformweb-based interface, in a very cost-effective way.

In addition to continuing the development of the environment, our current goalsinclude extending the library of functions used to generate the graphical userinterface, and increasing the interoperability features of the server, especially withregard to the communication with databases and other agents through high-levelprotocols. A demonstration version of the system we have described in this papercan be accessed from the T-IDDM project home page (http://aim.unipv.it/projects/tiddm ).

Acknowledgements

The authors sincerely thank Cristiano Canobbio, Stefania Montani, and Cris-tiana Larizza for their helpful cooperation. This work is supported in part by EUgrant HC-1047.


References

[1] Almasi G, Suvaiala A, Muslea I, Cascaval C, Davis T, Jagannathan V. Web*—a technology tomake information available on the web. In: Proceedings of the Fourth Workshop on EnablingTechnologies: Infrastructure for Collaborative Enterprises. 1995:8–11.

[2] Bellazzi R, Riva A, Stefanelli M, Fiocchi S. Long term management of diabetic patients: adistributed architecture. In: Brender J, Christensen JP, Scherrer JR, McNair P, editors. Proceedingsof MIE 96. IOS Press, 1996;34:88–92.

[3] Cimino JJ, Socratous SA, Clayton PD. Internet as a clinical information system: applicationdevelopment using the world-wide web. J Am Med Inform Assoc 1995;2(5):273–84.

[4] Detmer WM, Shortliffe EH. A model of clinical query management that supports integration ofbiomedical information over the world wide web. In: Nineteenth Annual Symposium on ComputerApplications in Medical Care. New Orleans, LA, 1995:898–902.

[5] Larizza C, Bellazzi R, Riva A. Temporal abstractions for diabetic patients management. In:Keravnou E, Garbay C, Baud R, Wyatt J, editors. Proceedings of AIME 97, number 1211 inLecture Notes in Artificial Intelligence. Springer, 1997:319–330.

[6] Musen MA. Dimensions of knowledge sharing and reuse. Comput Biomed Res 1992;25:435–67.[7] Rice J, Farquhar A, Piernot P, Gruber T. Lessons learned using the web as an application interface.

Technical Report KSL-95–69, Knowledge Systems Laboratory, Department of Computer Science,University of Stanford, September 1995.

[8] Riva A, Bellazzi R. High level control strategies for diabetes therapy. In: Barahona P, Stefanelli M,Wyatt J, editors. Proceedings of the Fifth Conference on Artificial Intelligence in Medicine Europe,number 934 in Lecture Notes in Artificial Intelligence. Springer, 1995:185–196.

[9] Riva A, Bellazzi R. Distributed AI technologies for patient management. In: Proceedings of TheAAAI Spring Symposium on Artificial Intelligence in Medicine. Stanford, CA, 1996:144–148.

[10] Riva A, Ramoni M. Lispweb: a specialized HTTP server for distributed AI applications. ComputNetw ISDN Sys 1996;28(711):953–61.

a development environment for knowledge-based medical applications on the world-wide web

Documents