PerspectivesAre you interested in submitting a Perspective Article? Be sure to read The Science Advisory Board's Editorial Guides for Perspective Articles. Click here. Telemicroscopy over the Internet by Ravi Shankar Nagarajan Introduction A telepathology system includes two basic tasks. 1) Control of a remote microscope, which would minimally allow for the transfer of images from the microscope to an expert. 2) Adatabase for the storage of patient data, session information, etc. By using a modular design it is easily possible to implement these tasks as separate applications. For second opinion consultations, the availability of primary data to many experts is most important. A very promising approach in this direction was the introduction of web-based technology. Instead of using a special, microscope specific software package for the expert to operate the remote microscope the functionality is embedded into a JAVA enhanced web page, so the microscope can be operated using a common web browser like Internet Explorer or Netscape. This increased functionality allows any pathologist with an Internet connection to act as a potential expert provided online access to the microscope server can be established. Firewall and Co. Unfortunately, establishing an Internet connection between two computers located in different hospitals is usually not as simple as it may seem. At almost any hospital, where probably most pathologists' offices are located, Internet connections are secured by so called firewalls. A firewall is basically a filter that allows only connections using standard protocols (at least HTTP) and only from inside the hospital (i.e., the Intranet) to the outside (i.e, the Internet). Therefore a direct connection of two computers located in two different hospitals over the Internet is not possible, because every attempt to connect to the other end will be blocked by the other's firewall. Instead, it is possible for both computers to connect to a server located in the Internet that routes the traffic between the two end stations (cf. fig. 1, the yellow route). Therefore the "microscope server", the applications that physically controls the microscope, and the web server where the JAVA applet for the remote user is located are separated into different applications running on different computers (cf. fig. 1).  Figure 1: The set-up of the telepathology system described in this paper. For second opinion consultation, the network connection between non-expert and expert is established over Internet and an external www-server (yellow line). For intraoperative diagnosis, where an open Internet connection is not reliable enough, it is possible to run the www-server application on the non-expert's computer that is connection to the microscope. The network link can be established over a 'private' ISDN-line. For intraoperative diagnosis reliability is far more important than for second opinion consultations. To circumvent eventual interruptions of the open Internet it is easily possible to run the www server application on the computer that controls the microscope and to establish the network connection over virtually private ISDN lines, either directly or via LAN to LAN connection, as most available systems do (cf. fig. 1, the blue route). However, it is possible to the same system for intraoperative diagnosis (over ISDN) as well as for second opinion consultations (using internet over an external server). As we have seen, the client side (JAVA applet) and networking can be design to allow platform and location independent operation. However, there are constraints that cannot be removed so easily: 1) automatic microscopes are very vendor specific and not standardised and 2) the integration of the system into a hospital's environment may be specific for different hospitals. The adaptation of a complex system to many different hardware types is often very difficult. If a system is built of clearly defined modules (cg fig. 1) and, most important, if the communication of between the different modules is standardised and published, it is much easier to adapt one module while leaving the rest unchanged. ### << Previous Next >> [ View All Perspectives ] |
|