A DBMS-based Medical Teleconferencing System

Abstract

This article presents the design of a medical teleconferencing system that is integrated with a multimedia patient database and incorporates easy-to-use tools and functions to effectively support collaborative work between physicians in remote locations. The design provides a virtual workspace that allows physicians to collectively view various kinds of patient data. By integrating the teleconferencing function into this workspace, physicians are able to conduct conferences using the same interface and have real-time access to the database during conference sessions. The authors have implemented a prototype based on this design. The prototype uses a high-speed network test bed and a manually created substitute for the integrated patient database.

The meaning of telemedicine is growing to encompass a wide range of telecommunication and information technologies. Telemedicine is the interactive audiovisual communication between health care providers and their patients and among health care providers regardless of geographic distance.^1–4

In this article, we describe the design of a medical teleconferencing system (MTS) that integrates a telemedicine system and patient database to provide a “virtual workspace” for participating physicians. We briefly describe the application modules used in a prototype implementation to manage conference data and perform remote query processes for the synchronization of teleconference data.

Background

Although many trials of telemedicine systems have been performed, most were restricted to simple trials or pilot projects. Several telemedicine projects have connected a rural clinic with an urban hospital or an island clinic with a community hospital. Unfortunately, none of these projects survived the termination of grant funding. The Institute of Medicine (IOM) has reported that, despite more than 30 years of technologic development and demonstration projects, conclusive evidence of the efficiency and cost-effectiveness of telemedicine is only sparse in the literature. The IOM identified several contemporary restrictions on telemedicine development, including high telecommunication costs, awkward and quickly outdated technology, low patient volume, lack of physician interest, and limited insurance coverage.⁵ In addition to the limitations disclosed by IOM, the authors recognized the time-consuming and laborious nature of telemedicine. Technical staff and doctors are usually required to spend substantially more time preparing for a telemedicine session than conducting the session itself. This is one reason for the limited physician interest in telemedicine projects.

Most conventional telemedicine systems work in a so-called “copy-and-synchronize” mode, which requires that conference material be prepared prior to the session and copied onto local disks at every site involved. Enormous time and work are required to convert patient data into a format suitable for the telemedicine system. Also in such a set-up, data are not directly retrieved from the database at the time of the teleconference session. During the session, discussions concerning data that have not been provided in the conference material cannot be effectively supported.

For effective communication, one of the most important features of a teleconferencing system is customization for a smooth conference process, particularly for ease of handling and presenting material. During a telemedicine session, large quantities of materials and data need to be discussed in a limited time. Presenters are sometimes asked to skip points or make a very brief summary of a patient's illness. Therefore, tools for better presentation and arrangement of patient data are the key components for successful implementation of a telemedicine system. Unfortunately, most conventional telemedicine software packages fail to provide versatile tools for the easy management of telemedicine sessions.

We propose an MTS that can be used for teleconference sessions by physicians in different hospitals with institutional links. The MTS connects two hospitals for a case conference and delivers textual data as well as multimedia data such as x-ray images and angiographic video images. Easy-to-use tools that manage the data and edit whole sequences of presentation materials are the key elements. Our current prototype implementation is based on a central server model into which all contents of the patient database have been manually integrated.

Design Objectives

The common goal of a telemedicine system is to provide and improve medical decision making among participating physicians. To achieve this goal, distributed and fragmented patient records should be rearranged into an easy-to-find structure in the telemedicine system. Another important criterion for a successful telemedicine system is the inclusion of time-saving tools that can be used to present meaningful clinical information succinctly during a teleconference.

The following objectives were established for MTS design:

• The design must be directly integrated with the existing clinical database to allow information needed during the conference to be retrieved quickly and easily

• The design must provide a single, uniform interface so that the medical professionals can view patient data in a coherent and consistent manner

• The design must be more than a mere interconnection of different applications. The system must provide a virtual shared workspace that allows participants to organize the various forms of conference-related data and present such materials systematically for more effective conferencing.

The critical nature of the patient information requires high-quality display technology and support for comprehensive multimedia capability.

System Architecture and Components

Overview of Medical Teleconference System

We designed an MTS that comprises a database server and client teleconferencing applications. The main role of the database server, in addition to hosting patient data, is to generate and store conference files. Users who will give presentations at the teleconference prepare presentation sequences beforehand and store relevant information into conference files. They can review the presentation materials, edit the presentation sequence, and store the presentation sequence information into conference files.

The client teleconferencing application is a set of modules for conference material preparation, remote query processing, and conference control. For preparing teleconference material, it is designed to get patient data from the hospital information system and store the information into conference files of the MTS database server. It also performs special queries. As the MTS database server has the highest access priority for the client application, the client application first searches the patient information stored in the conference files. If the client application fails to find the data in the conference files, it performs special queries to find the data in the hospital information database.

Database Server Module

The database server is directly connected to the client systems so that the entire contents of the database are available as a conference resource. Figure 1▶ shows the overall architecture of the MTS, in which three clients communicate with the database server via a high-speed network. The client application is designed to be run on each participant's system.

Figure 1.

Architecture of DBMS-based medical teleconferencing system.

The MTS database primarily stores patient records in a simple structured format, as well as a variety of multimedia data and information for controlling the conference sequence. The system provides users with a conference file that contains reference information for the conference. The logical structure of the conference file is shown in Figure 2▶.

Figure 2.

Logical structure of the confeence file.

The conference content (CC) component includes patient profile, name of physician in charge, doctor's notes, patient history, physical examination results, and laboratory test results. Rather than making copies of patient data, the conference content maintains a list of pointers to the associated data contained in the database. The data are classified into six types according to their characteristics:

• The memo consists of textual data, including chief complaints, systemic reviews, notes, medical history, and examination notes.

• The grid table is a table of records describing multimedia information generated from CT, MRI, and x-ray examinations.

• The spreadsheet displays the numeric results of each examination. Rows in the spreadsheet contain various examination values, such as complete blood count and other hematologic data.

• Image data consist of scanned images from x-ray, CT, MRI, and SPECT examinations.

• Audio data consist of sound records encoded in WAVE format.

• Video data consist of animated images generated from angiographic, ultrasonographic, and other examinations.

The conference metadata (CM) component contains data items needed for the control of the conference process. It is composed of four parts—profile, sequence information, derived data information, and annotation information. The profile summarizes pertinent introductory information about a specific conference session, including author, title, theme, time of the conference, and remarks. The sequence information is a step-by-step procedural definition of a conference session and contains pointers to the conference contents. It is generated by the marking of leaf nodes on a patient record tree. It can be modified at any time by use of the sequence editor (Figure 3▶).

Figure 3.

Patient record tree and sequence editor.

The derived data information includes a “group view” and “transition graph view,” which are special views synthesized with different basic data views. During early design stages, users of MTS requested a virtual workspace to integrate patient text-based data and graphic information.^6,7 The group view and the transition graph view are two window-like models developed to address this requirement. The group view is a thumbnail viewer that provides an integrated view of a group of CT, MRI, or x-ray images and angiography videos as a single episode. The transition graph view is used to analyze the trends over time of various values selected from the spreadsheet data, as shown in Figure 4▶. The annotation information is a set of textual and geometric objects (e.g., circles, rectangles, and arrows) that are annotated onto images.

Figure 4.

Transition graph for the cumulative display of clinical test results.

Client Application Module

The client module is subdivided into a database module and a conference management module, as shown in Figure 5▶. When the user requests the next view at a conference, the conference management module invokes the remote query module to retrieve the necessary data. User actions captured by the user interface are converted into the motion parameters required for the remote database query module. This module generates a query according to the submitted criteria, passes it to the database server, and then delivers the retrieved result to the appropriate data viewer module.

Figure 5.

The module architecture of a client application.

Modules in the client program function as follows:

• The data navigator is closely related to the patient record tree shown in Figure 3▶. It enables users to quickly navigate any part of the patient record and gives participants an integrated view of many types of patient data. Basically, the patient record tree can be traversed either randomly or in a predetermined order, as specified in the sequence information, showing the corresponding contents dynamically at each step. To achieve such a data navigation facility, each leaf node of the patient tree has database query information that includes SQL parameters. Thus, when a user clicks on a node, related conference contents are retrieved from the database and their appropriate view instances are dynamically generated.

• The data viewer provides “view templates” for the six basic types of patient data. For example, the image viewer supports image-processing functions such as zooming, panning, and annotation, and the video viewer has a repeating function that can be used to observe a critical portion of a video repeatedly.

• The session manager provides functions to manage the conference session. It enables the participants to start, find, join, and leave a session. It automatically constructs a virtual workspace when a new session is initiated, and it stores conference conclusions and recommendations.

• The sequence manager manages the conference sequence and prefetches sequentially referenced conference content. To manage the conference program, a sequence editor is implemented, in which the view sequence can be defined according to the predetermined conference scenario. For prefetching, a method called “informed prefetching” was adopted.^8–10

• The synchronization manager synchronizes client actions through the following steps. The client PC, as an initiator, requests patient data from the database using the conference metadata in its local memory. At the same time, it sends a message to the other client PC to synchronize the request action. As soon as the other client receives the synchronization message, it requests the same patient data from the database, which simultaneously processes the identical requests from both client PCs and then forwards the resultant data to each client (Figure 6▶).

Figure 6.

Synchronization process for client retrievals.

Status Report

We developed a prototype that implements the design described here. We were fortunate enough to test our system over a high-speed network testbed in which the central database server and the client systems for remote participants were all connected to an ATM (asynchronous transfer mode)–based B-ISDN network via 155-Mbps optical fiber links. There were virtually no problems due to communication delays. However, because native ATM networks cannot support TCP/IP directly, communication was carried out on top of an “IP-over-ATM” intermediate layer. The test environment is summarized in Table 1▶.

Table 1 ▪ .

Test Environment

	Item	Description
Client PC:	Hardware	Intel Pentium Pro with 64-MB main memory and 2-GB disk
		Dual monitor driven by dual analog PCI VGA card
	Software	Windows 95 operating system
	Network	155 Mbps ATM PCI card
Central server:	Hardware	SGI Origin200 server with 512-MB main memory and 12-GB disk
	Software	IRIX operating system
		UniSQL DBMS
	Network	155-Mbps ATM PCI card
Network:	Backbone	Dedicated ATM switch with guaranteed 155 Mbps
	Local area network	Distance less than 1 km
	Wide area network	Distance about 100 km linked through dedicated ATM switches with guaranteed 155 Mbps
Scenarios:	Case consultation	Between two physicians in remote locations (WAN). The server sits on one side.
	Case conference	Resident physicians gathered in one review room. The system is used as a presentation tool accessing the server locally (LAN). Presentation could be seen at a remote location using teleconference features.
Database:	Size	10 GB/100 patients
	Tables	Queries and programs written for each data source. Some degree of manual editing involved.
	Multimedia data	Most images and video data existed in analog forms. They were digitized for this purpose.

To start a conference, the conference initiator must ask participants to log onto the conference by executing their own client program and accessing a conference session. When a conference session is established, a workspace is automatically created and the conference proceeds in the order predetermined by the conference file. However, if any of the conference participants ask for data that are not included in the file, the data can be retrieved dynamically from the database by use of a tree-like navigation menu. This also means that a conference session can proceed without any user preparation. Two or more users can simply log on from remote locations and start discussing certain issues while looking at the synchronized database interfaces. All the activities that may occur during the conference, such as adding annotation to an existing image or writing a concluding note for the conference, can be appended as a part of the conference file and maintained permanently for later use.

Figure 7▶ shows a typical view of the MTS user interface. To view an image, the user must actuate the image viewer by clicking the appropriate item in the grid table. The image viewer provides tools that allow users to add annotations to the images. If an image item selected from the thumbnail table is linked to MPEG data, the video viewer is automatically executed. A toggle switch allows a user to view the desired recording by setting the start and end points using a slide bar. Both the image viewer and the video viewer display data on a separate monitor, so that physicians can see various types of data simultaneously. A white board with full annotation capability is also provided.

Figure 7.

Typical view of the medical teleconferencing system user interface.

The MTS has been tested in medical settings to verify its practical effectiveness. Specifically, it has been tested in two different set-ups—case consultation and case review. In the first set-up, a physician at a local clinic might consult a specialist at a general hospital about a serious case, such as that of a 60-year-old man who has breathing difficulties. The physicians involved in this test were impressed, in part, by the speed at which high-quality medical images were provided and, more, by the convenience provided by the integrated workspace view, along with our synchronization feature.

In the second set-up, the MTS can be used by resident physicians in a hospital to review cases. The physicians who used the system to present their materials for this purpose expressed satisfaction that its user interface allowed them to easily view and share patient information without the need to compile physical files and prepare slides for overhead projection. They felt that the MTS supports their clinical activities more effectively than do conventional conference tools. However, some delays and awkwardness in the synchronization for video data control occurred because the video viewer requires considerable CPU and memory resources.

The patient data integration challenge was too big an issue to be included in the prototype project scope, because the hospital information system comprises several independent distributed and heterogeneous systems. Instead, we have built the MTS database from these disparate systems, relying heavily on skilled operators who would write database queries to retrieve relevant data from a source and write programs that would transform, clean the data, and then populate our database. The majority of multimedia data were collected from scratch; image data were digitized using a high-resolution scanner and digital camera, and analog video data were collected using a video capture board equipped with an MPEG encoder.

Discussion

The current project has achieved its goal of demonstrating that the integration of the teleconference functionality with clinical database retrieval is a promising approach to physician-to-physician teleconferencing. We concluded that database retrieval and network bandwidth were the two major determining factors of system performance.¹¹ This was particularly true in situations that required real-time database access, when rapid and accurate data delivery was critical for conference continuity.

For effective database retrieval, we constructed an index system using object identifiers as primary keys for each object type.¹² To resolve the network delay problem, which may have been caused by the transmission of multimedia data, a prefetching algorithm was used to prefetch multimedia data at the beginning of the conference, leaving adequate network bandwidth for the transmission of other data. Specifically, we adapted a data-caching mechanism called “informed prefetching,” which aggressively uses knowledge of future access to conference contents. As a result, the system can significantly reduce network latency time during a conference session and take full advantage of its limited repository. Furthermore, to reduce the volume of message exchange resulting from the synchronization of mouse movement, the system provides movement support only when a partner's action has some significance.

Although the size of the prototype database was relatively small (100 patients) and the process of building it was laborious, the effort has successfully demonstrated the utility of a truly integrated patient database.

One of the most important features of the system is that it offers participants the ability to retrieve data directly from databases while a conference is in progress. This was made possible by building a multimedia database user interface that allows users to view medical records in an integrated manner and by adding a conferencing facility to this workspace. Users are able to discuss cases while using a database interface with which they are familiar. The reduction of response time and the mimicking of the access patterns of doctors promise to provide a teleconferencing system that is tightly coupled with a clinical database and that provides practical advice from remote sites.