Telepathology: Design of a Modular System

Although telepathology systems have been developed for more than a decade, they are still not a widespread tool for routine diagnostic applications. Lacking interoperability, software that is not satisfying user needs as well as high costs have been identified as reasons. In this paper we would like to demonstrate that with a clear separation of the tasks required for a telepathology application, telepathology systems can be built in a modular way, where many modules can be implemented using standard software components. With such a modular design, systems can be easily adapted to changing user needs and new technological developments and it is easier to integrate modular systems into existing environments.


Introduction
Telepathology (telehistology and telecytology) can be defined from two points of view. (1) Seen as an interaction of physicians, telepathology can be understood as a structured dialogue between an expert an a non-expert in the special field of pathology. The nonexpert is always a person, the expert can be a person or even a device. (2) Describing from a technological point of view, telepathology systems are something like specialised fax tools for physicians.
The year of birth for telepathology can be designated as 1986. In this year Weinstein et al. [17] proposed a system with robotic microscope and video imaging to serve as infrastructure for telepathology networks. In the past 14 years various groups at multiple places have taken the initiative to institute the method [7][8][9][10]. The number of publications increased considerably [9]. National and international working groups have been formed, at the beginning with the sole aim to exchange experiences, recently with the aim to define general rules [1].
At the present time the method seems to be in full development still. Two main reasons are responsible for it: (1) Permanently new technologies are appearing and (2) the not yet established way of the method in everyday's use. For the present the interest of clinically oriented pathologists -but also surgeons -in the possibilities of telehistology and telecytology is steadily increasing. Both professional fields have recognised the potential of telepathology as an instrument for diagnostics but also for means of quality control of diagnostic methods. To that, "second opinions" are increasingly requested in histological and cytological diagnostics. Telepathology is available for that purpose as a simple new method. With the tremendous development of the Internet and multimedia technologies in general, it is therefore striking that there is not a more widespread use of telepathology. High costs, inefficient software and lacking interoperability of existing telepathology systems have been described as some of the reasons [19].
In this paper we will discuss some of our recent experiences at implementing and testing telepathology systems based on a modular system design. Specifically, we will discuss how modular design helps making adaptions to user needs, reducing costs and that a modular design is a fundamental premise for the technical standardisation of the involved interfaces, as it is desired by the European Society for Analytical and Cellular Pathology (ESACP).

Types of telepathology
Basically, telepathology is always a dialogue between someone seeking advice -the Non-expert -and someone who can give the desired advice -the Expert. Most publications on telepathology consider only the classical situation, like a intraoperative diagnosis or "second opinion" consultation, where the non-expert has some microscope slide he wants to have examined by an expert. There are basically two ways of practicing telepathology applications for these situations [18,19]: (1) "store and forward" systems, where the nonexpert makes a selection of images which are then sent to the expert (e.g., [3,5]) and (2) interactive systems, where the expert can remote control the non-expert's microscope to make the selection of images himself (e.g., [2,20]).
Besides these diagnostic consultations there are other aspects of telepathology where the "expert" is actually a computer device. With the EUROQUANT server, developed by a European research project EU-ROPATH, for example, it is possible to remotely quantify DNA ploidy and to control the quality of DNA quantifications [6].

Telepathology in Basel
Since 1990 three systems for diagnostic telepathology -according to the state of technical possibilities of their time -have been developed at the Institute for Pathology of the University Basel ( Table 1).
The first developments date back to 1990 and resulted in a telepathology system which is now in use since 1992 with the regional hospital of Samedan in the Swiss Alps [12,13]. The system -referred to as sys-tem#1 from now on -consists of two Macintosh workstations which are connected over ISDN. The pathologist in Basel can operate the microscope in Samedan through the application-sharing software Timbuctu. Patient data, images and reports are stored with the help of the database Omnis. This system proofed as a valuable tool for intraoperative diagnostics (number of case studied: 139) [16].
In 1996 we started with the development of a successor system to system#1 in collaboration with the Technical Highschool of Basel (FHBB). This second system (#2) is based on Microsoft NetMeeting and has several improvements over system#1 like, e.g., live video preview, a overview image, discussion mode, etc. Data and images are stored in a FileMaker database.
Recent developments in Internet technology -like the platform independent programming language JAVA -make it possible to use the familiar web environment for telemicroscopy [4,20]. To evaluate the possibilities of such a web based approach we have developed an experimental telepathology system (#3) based on a http server and the Common Object Request Broker Architecture (CORBA), an industry standard for the implementation of distributed software.
One design goal with all three systems was to use as many "off the shelf" components as possible. The main task is then to put these components together in an intelligent way to provide a functional and user friendly telepathology system. Such a modular approach has proven very valuable as it allows the exchange of one module should a better solution become available. To that it is relatively easy to adapt the system (or a part of it) to a new environment, e.g., another microscope or another computer system.

Modular design
In order to use such "off the shelf" components, it is important to clearly identify the different tasks in a telepathology application and to implement them as independent modules. To clarify what modules are needed in a telepathology system we will give a brief overview here ( Table 1).
As "Image acquisition" we consider the combination of video camera, frame grabber card and image grabbing software which is responsible for the acquisition of images from the microscope. The "image acquisition" can be used either in an dynamic telepathology session as well as to prepare images for a static consultation.
The module "Instrument management" includes all necessities to operate a modern robot microscope. This includes in a minimal setup an xy-scanning table and additionally, depending on the microscope, the z-axis, objective revolver, illumination, etc. To that it is desirable to have the possibility of generating an overview image of the whole slide (map) which is a tremendous help for orientation. As these two modules are both tightly coupled to the microscope, it is often convenient to link both modules into one application as has been done in system#1 and system#2.
"Remote control" is the tool which allows the expert at a remote site to operate the non-expert's microscope over the network. In system#1 and system#2 an application-sharing software, which enables to share complete applications over the network, is used. Sys-tem#3 introduces a distinct client/server architecture.
A very important module for the routine use of telepathology is a "data storage" using a database ap-  1 These elements were primarily not available on the free market and had to be programmed specifically for that purpose. 2 To ensure privacy of sensitive data sent by email we use the RSA public PGP encryption method (www.pgpi.org).
plication. For legal as well as for other purposes (e.g., billing) all data -like patient data, images, reports and billing information -should be saved in a database. As one patient can have more than one examination and one examination may consist of more than one "job" we use a database with four distinct tables: PATIENT, TASK, JOB and OBJECT [14,16] (Fig. 1). A Job is generally one examination of a distinct organ. Every job consists of several Objects (e.g., images) which are used for diagnosis. Using some characteristic parameter (date, time, physician) of the job and the objectnr, it is easy to generate a code that uniquely identifies every object. A Task is a unit for the administrative handling of the diagnostic or consultative demands. As one examination of a patient may consists of more that one telepathological session it is possible that a Task consists of more than one Job. The Patient table finally stores the personal information of a patient. In a real world situation, the Patient table and usually even  the Task table correspond to a hospital's central patient database, while the Job and the Object tables are usually located at the pathologist's ( Fig. 1).
Besides the preservation of data there is another function of database. A single Job including all corresponding Objects can be exported and sent to another pathologist for consultation. On the remote site, the expert can view all objects and can enter his report on that case. The report is then exported and sent back to In the case of dynamic telepathology "data transfer" is usually included in the remote control functionality (Timbuctu or NetMeeting). For static "store and forward" telepathology we also use email for data transfer. To ensure privacy of transferred data it is possible to use (1) a private network link (e.g., ISDN line); (2) to encrypt sensitive data prior to the transfer. We are using the public PGP (pretty good privacy: www.pgpi.org) method for encrypting data. Due to its asymmetric keys PGP has the advantage that data, once encrypted, can only be restored by the dedicated receiver.
While the "Network" is not really a module itself, it is quite useful to treat it separately. While for many applications the Internet is nowadays the most effective (inexpensive and fast) connections, for some applications, like, e.g., intraoperative diagnosis where reliability is probably the most important criteria, it may still be reasonable to establish a private network connection using, e.g., ISDN. Apart from a very fixed direct computer to computer connection, it may also be useful to connect two Local Area Networks (LAN) using routers or to connect one computer (e.g., the non-expert at a regional hospital) to a remote LAN (Fig. 2).

Discussion of modules implemented
In this section we want to discuss some of our experience in using as well as developing telepathology systems. Besides the advantages of a modular design, we will also address the pros and cons of videoconferencing, platform independence and some possibilities for the implementation of network connections.

Modules should be as independent as possible
Implementing a system based on distinct modules has several advantages. First of all many of the modules have a standard functionality and can therefore be implemented using inexpensive, "off the shelf" components like image acquisition software or Net-Meeting, a videoconferencing application. Additionally, such standard software is usually well tested and therefore its functionality is very stable.
As only few of the modules are directly depending on others, it is possible to develop each of them relatively independently. In system#2 "image acquisition", database and networking were developed at three different locations and assembled only later.
As another consequence of the modular design it is possible to adapt the system to many new environments. For example, one of the authors (P.M.), at the Ophthalmology Department of the University Hospital of Basel, is using a combination of the two modules "image acquisition" and "database" of system#2 and an ordinary light microscope with a video camera as a static "store and forward" system. (While originally designed on Windows PCs, P.M. is even using it on a Macintosh.) A problem encountered is the fact that probably the central database system for storing patient data differs from the database system used for telepathology. A modular system using standard database software allows adaptions to the user's needs and leaves the possibility of implementing an interface to the respective central information system.

Pros and contras of videoconferencing (NetMeeting)
As described above and in other papers [11,12] it is possible to implement a full-fledged telepathology system based on an application-sharing and/or videoconferencing application. The main advantage of such a conferencing system is certainly its ease of implementation. While for interactive consultation this setup is quite useful [12,13], there some limitations for a more general use. As the control of the non-expert's computer is taken over by the expert via applicationsharing, this can be a major security problem.
Besides this, our experience has shown that the use of this method of collaboration in a productive way requires an effort of training not to be underestimated on the side of the expert, who operates the system. While, with some training, remote control over applicationsharing is suitable for people using a pointer device like the mouse, it is a major obstacle for a computer process to do so. Therefore it is not possible to develop intelligent client software that could, for example, store images automatically into a database. With a videoconferencing system many tasks ultimately remain to the operator of the system -the pathologist.

Platform independence
There is no platform independent standard for an application-sharing mode thus interaction between different computer platforms is not easily possible. While video, and image transmission through the whiteboard are no problem, when images are displayed by special remote applications and viewed over applicationsharing -an interactive overview image of the slide, for example -we have observed several problems with colour reproduction due to incompatibilities between different hardware (even between computers running the same operating system).
One way towards real platform independence is a client/server architecture like the NCMIR [4], the TeleMic project [15,20] or the CORBA based sys-tem#3.
Using an Internet technology together with the very general HL-7 and DICOM standards, such a client/server system can be really a platform independent telepathology solution for all the TP scenarios explained above.
Also the database solution shown above is not yet as platform independent as it could be. Most desirable would be a standardised data exchange format which is suitable for the exchange of electronic patient files including objects like images.

Flexible network connections
Today, the Internet is certainly a very interesting candidate for telepathology. It is fast, inexpensive and -besides the plain old telephone -probably the most widespread network. Furthermore, for the near future a very fast Internet access via UMTS or ADSL technology is to be expected. Due to its open nature, the Internet is also a very insecure network. To guarantee privacy, any patient data have to be encrypted (e.g., with public encryption utility PGP). Another consequence is that most hospitals have secured their intranets with firewalls. A firewall basically prevents computers from outside the hospital to access any resource inside the hospital, so it is often not directly possible to use the hospitals network for interactive, dynamic telepathology.
The most reasonable alternative to the Internet is the use of the Integrated Services Digital Network (ISDN) as a medium for point-to point connections. With a transfer rate of 128 kb/s it is fast enough, even for dynamic telepathology. We have successfully tested two systems using remote control and live video (#2 and #3) with standard ISDN connections.
Some of the possible ways of establishing connections using ISDN are summarised in Fig. 2. The simplest way, a direct PC-to-PC connection over ISDN, restricts the operation of the system to a dedicated computer at the expert's side. A much more flexible solution is the use of a Remote Access Service (RAS). Here the non-expert establishes a ISDN connection to an RAS-server on the expert's side and thereby becomes virtually part of the expert's LAN. The telepathology system can now be used from any workstation connected to the LAN, so the experts no longer need to use a special machine for telepathology but can do it from the desktop computer in their office. Additionally, with RAS more than one sessions could be performed at the same time.

Conclusions
During the last few years telepathology has become a useful help for remote diagnosis and second opinion consultations. There are however still several problems remaining which have prevented a widespread use of this technology so far [19]. The problem of incompatibility of commercial systems have been addressed to some extent by recent developments trying to use common Internet technology, like the TeleMic system of the Berlin group [4,20] or the CORBA based system described as system#3 in this paper. However, in order to overcome the incompatibilities between different systems a technical standard for telepathology systems should be created. For that purpose it is inevitable to clearly specify all the interfaces needed by a telepathological application, a task that is, in our opinion, almost impossible without an open, modular design, where all functions are clearly separated into distinct components.
Besides the technical aspects there are also the financial aspects to be considered. Classical systems which can only be purchased as a whole and which have their distinct, often quite consumptive needs of bandwidth etc. are usually rather costly -for acquisition as well as during operation. Modular design can help to reduce the costs dramatically, as a modular system can be well adapted to the user needs without losing the possibility of later upgrading if increased functionality is desired. A static store-andforward system can be implemented almost for free. If encrypted email is used for data transfer also the running costs are minimal. Adding a fast network connection, a motorised scanning table and a software module for "instrument management", the store-and-forward system can easily be transformed to a dynamic system later.
One possible way of overcoming the limitations of videoconferencing based systems, we see in the use of a client/server architecture. Examples of such an architecture are the NCMIR project [4], the TeleMic system of the Berlin group [20] and system#3 described in this paper, which was specifically developed to examine the possibilities of an open client/server architecture in combination with a modular design. As an in depth comparison of videoconferencing vs. client/server architecture will certainly be out of the scope of this publication, it is in the process of being published in another paper -together with a more concise proposition for technical standards.
To summarise, we think that with a modular design and an open, standardised client/server architecture it will be possible to overcome most of the remaining obstacles which have so far prevented a more widespread use of telepathology as a routine diagnostic tool. A routine diagnostic tool is fully integrated in the common working process and should not require much specialised knowledge for its application than handling a fax machine.