A Communication Server For Telemedicine Applications - Information ...

IEEE TRANSACTIONS ON INFORMATION TECHNOLOGY IN BIOMEDICINE, VOL. 1, NO. 3, SEPTEMBER 1997

205

Communications A Communication Server for Telemedicine Applications Jing Bai, Bingyi Hu, Yonghong Zhang, and Datian Ye

Abstract— The telemedicine applications, in some cases, need multipoint-to-multipoint communication. To meet the requirement of telemedicine communication, the development of a medical communication server is proposed in this paper. To make a working, as well as cost-effective, communication platform for the telemedicine applications, a specially designed communication server model is proposed in this work. This server is able to provide an effective multipoint-to-multipoint communication service for any level applications in telemedicine. The implementation program of this server is developed in a Windows ’95 environment by using a winsocket. The trial application testing in a telemonitoring system is also presented to demonstrate the feasibility of taking such a structure with the server. By using the architecture of such a communication server in telemedicine applications, the multipoint-to-multipoint communication is easily managed and the communication processes are simplified and well controlled by the server. Index Terms— Communication server, multipoint communication, telemedicine.

I. INTRODUCTION

T

ELEMEDICINE is forming a new architecture in health care services. Recent breakthroughs in communication technologies have stimulated the development and demonstration projects in telemedicine. Taking advantage of telecommunication, medical electronics, and computer technologies, telemedicine has the potential to reduce health care expense, to improve health care service in remote areas, and to support modern home health care. There are many different disciplines in telemedicine, such as teleradiology, telemonitoring, teleconsultation, teleconference, and telepsychiatry [1]. The common problem met during the development of a telemedicine system is how to integrate the existing techniques to meet the requirements for telemedicine applications [2]. Telemedicine applications may be classified into three levels: the application within the hospital, such as the information transfer between different departments, the application between hospitals, such as a teleconference between hospitals, and the application between the outpatient and the hospital or the doctors, such as home telemonitoring. Among these applications, the requirements for the communication mode and rate are different. The information transferred may be in different forms, such as a digital data file, text, or medical imaging, and thus, the length of communication flow is also a variable. Furthermore, upon different application situations, the communication flow maybe single directed or multiple directed. Therefore, the communication of telemedicine system is complicated. Many telemedicine applications reported are based on the point-to-point communication mode [2]–[5], and its application is limited to the two users. There are also a number of multipoint-to-multipoint telemedicine systems developed, based upon Manuscript received April 29, 1997; revised October 2, 1997. This work was supported in part by the Chinese National Natural Science Foundation and the State Education Commission. The authors are with the Department of Electrical Engineering, The School of Life Science and Engineering, Tsinghua University, Beijing 100084, China (e-mail: [email protected]). Publisher Item Identifier S 1089-7771(97)09185-1.

Fig. 1. The general telemedicine communication network structure.

the broadband networks [6], [7], which are not available for most hospitals in China. On the other hand, the Internet has provided a good example of using various network frames and multiple logical channels for multipoint communications. But, without special communication management, the multiconnections and repeated data transferring will cause the communication traffic jam. To make a working, as well as cost-effective, communication platform for the telemedicine applications, a specially designed communication server model is proposed in this work. This server is able to provide an effective multipoint-to-multipoint communication service for any level applications in telemedicine. The development and implementation examples are also reported. II. THE CONCEPT OF MEDICAL COMMUNICATION SERVER Usually, a medical network consists of both low-speed communication channels and high-speed communication channels. The low-speed channels connect outside medical specialists and patients with medical centers. The high-speed channels setup the connection within and also among medical centers. Such a structure is described with Fig. 1. In the application of telemedicine, the medical information usually needs to be distributed among medical doctors and display, archival, and analysis devices. For example, when Patient A is requested to send data to the medical specialists A and C, by using the traditional method, the patient has to send data to specialist A first and then the same data to specialist C. In this case, the data are transferred twice in the channel connecting to the Patient A. This kind of communication style is not only complicated, but also may crowd the communication channel. If a service in the Medical Center A was able to receive the data packages of Patient A and deliver the packages to specialists A and C, the patient’s operation would be simplified. The method requested by patients and served by a special application gives out a basic client/server structure. To meet communication requirement for telemedicine applications, we introduce the concept of a medical communication server that is able to provide the service of multipoint-to-multipoint communication and has a simple connection with its clients. The architecture model of the logical connections of telemedicine applications through this communication server is presented by Fig. 2. To make an effective service for all clients, a star-topology is adopted in this communication service model. The telemedicine users and participants, medical information display, archival, and retrieving systems are all clients to the communication server. The communication among them are all under the control and through the services of the communication server. Based upon the architecture of electronic mail servers, there is one server for each local area network and there are bridges to connect different

1089–7771/97$10.00  1997 IEEE

206


Fig. 3. The data package format definition.

Fig. 2. The topology for the telemedicine communication server.

servers as shown in Fig. 2. The basic function of the communication server is to manage the communication between its clients, such as to receive, transfer, and distribute the medical information and to control the information exchanging direction, priority, and stream rate. Since such a server is able to exchange data packages with all clients, so each client is able to send to and receive information through the server. In the client’s view, he or she has only one connection with the server and only needs to send the communication request in a data package to the server according to the hospital’s protocol. To meet the special requirements in telemedicine applications, three operation modes are defined for the server as follows: Mode 1 is the communication control mode that is applied to set the client’s communication status; Mode 2 is a point-to-point mode that makes clients able to have point-to-point communication; Mode 3 is a group working mode that provides the multipoint-to-multipoint communication. In Mode 1, clients are able to exchange information with the server. The clients can request their server to preset the communication status related to their applications. The general operations for the clients working in this mode include obtaining information about users and groups with this server, logging in as a user in a group, inhibiting the receiving of special kinds of data packages, etc. This mode is used to make conversation between the server and the clients as well as to manage the client’s communication status. Mode 2 enables a client to have a private conversation with another client in the multipoint communication environment. Since the destination address is not necessary for a point-to-point communication, a socket connect is adopted in this mode because, in this case, the default destination is the other side of the socket. Mode 3 is a group-working mode. It provides the communication services for the members of a working group. In this mode, the server will distribute the information to all the members in the same group. This mode provides a multipoint-to-multipoint communication service. All the operation modes together provide a solution of the communication status management, the multipoint-to-multipoint communication, and the point-to-point communication in a multipoint communication environment. III. THE COMMUNICATION PROTOCOL According to the concept proposed above, the communication protocol for the server should include the connection and data packages. Because the “socket” is an interface of the Internet application layer and because it has been used in many applications, based upon the star-topology for the client/server structure, we adopt the socket as the communication server’s communication-connection protocol with each client. With the socket connection, the information transferring between the server and the clients is flattened. In order to enable the server to deliver or distribute the information to the correctdestination clients, a special data package format is defined, as shown in Fig. 3. This data package format includes the information of the

destination, the address of the client, the length of the data, and the data to be transferred. The first word of the data package is Flag Word, which indicates the destination address, and the following is the data to be transferred. The data type of the Flag Word is “word” with two bytes. The higherorder byte is for the operation code and the lower-order byte is for the address. By including the address and operation code, the operation mode and destination address of the data package is labeled on the data package. According to the different applications, the Flag Word in the data package can be defined differently. Considering the applications in telemedicine, the protocol for these two bytes is defined below. In the case of a data package sending from a client to the server, the higher-order byte in Flag Word may take the value of 0, 1, 2, or 3. While label “0” indicates that this package includes a communication command to the server, label “1” indicates that this package should be distributed to all clients working in the same group, label “2” indicates that this package is for a specified client with a given address in the lower order byte of this flag word, and label “3” indicates that this package should be distributed to all the clients connected with this server. Responding to the label “0,” the server will interpret and then execute the command. In this case, the server is working in Mode 1, as defined in previous section. Responding to the label “1,” the server will not interpret the data. Instead, the server will replace the destination address by the address of the sending client as the lowerorder byte in the Flag Word of the data package and distribute it to all the clients working in the same group. In this case, the server is working in its mode 3. Responding to the labels “2” and “3”, the server will do the same thing as when responding to the label “1,” but it only distribute the data to the defined destination clients. In the case of a data package sending from a server to clients, its high-order byte in Flag Word may take the value of “0,” “1,” “2,” and “3” too. In this case, the label of 0, 1, 2, or 3 indicates that this data package comes from their own working group, a specified client, and other working group, respectively. The source client address is included in the lower order byte of the Flag Word. Label “0” in this case means that the package is coming or going from the server. Usually, it contains the results of the server’s responding operation and the information required by the client. As shown in Fig. 2, among the clients connected to the server, there is a special client, which is connected to the other server as a bridge. We call it a bridge socket. This socket can be created by anyone of the clients. When it is created, it becomes the new member of the working group of its creator and the creating client is its owner. Whenever the client sends a package to this bridge socket, it will send this package to the server on the other end of the socket. When this socket receives a package from the other server, it packs the data package by replacing the address code with the sending router’s value and send the package to the owner client. If the socket receive a package with a higher order byte of “1,” it will ask the server to deliver it to all the clients in the same group. To create this bridge socket, the client needs only to send the command “Router” to the server. After the server receives this command, it will create a new bridge socket that connects the destination server described by the command. IV. IMPLEMENTATION OF THE MEDICAL COMMUNICATION SERVER Because of the popularity of the Microsoft Windows application, we use Microsoft Visual C++ as a programming tool to develop


the server application. According to the discussion above, the socket is the kernel of the communication server. All connections are based on the socket. For the Microsoft Windows applications, the “winsocket” can implement the functions of the socket. Therefore, all the applications that we are going to discuss below are based on the adoption of the “winsocket”. A client/server communication application should include two parts, one is the server program, the other is the client program. The telemedicine applications require the server program to be able to provide the service for various clients, such as the patients, medical doctors, storage devices, etc. To make use of the services provided by the server, the client program should provide a proper interface in order to work together with the server. By considering these requests, a structure of the server program and the interface function of the client program is established and presented in this part. Because the server connects many clients, it needs to deal with many communication events. If the server program tells the function “socket” of the Windows API to implement the socket connection, it has to run through a loop of status checking. This programming method will make the program more complicated and the loops will take big amount of CPU time. Instead of using the function socket of the API, the class “CSocket” is adopted to derive the listening-socket class and the client-socket class in this implementation program. The server program consists of an object of listening-socket class and many objects of client-socket class. The object of listening-socket class is created in the initial stage of the program. The objects of client-socket class are created when the server receives a connection request from any of the clients. Therefore, the task of the server is to deal with the events of these objects. Besides the object-oriented function, the server has another task, which is to manage the traffic of the communications among the clients. Thus, the structure of the server program consists of two parts. One is the objects and their data, the other is the communication traffic control related to the objects’ events. To manage the communication traffic, the server program makes up a table to store communication information of all the client-socket objects. The information includes connection status, client’s name, group number, receiving inhabit bits, bridge status, and bridge owner. The connection status indicates whether this socket connects a client or not. If a socket object has connected with a client, the status gives out client number. The client’s name and group number identify the client and his or her group. The receiving-inhabit bits tell the server what kind of packages will be refused by this client. The bridge status indicates the client’s three possible statuses: common client, bridge owner, and bridge. The value of the bridge owner is the bridge client number for the bridge owner or the owner’s client number for the bridge. All the information in this communication-status table can be updated by sending a command package to the server. The server program has another table that stores the information of the groups. It contains of a group name list and the member lists for each group. According to the protocol proposed for this communication server, many communication operations are related with the group. If a client wants to join a group operation, he must log in to the server with a user name of a specified group name. After he logs in, the server will add the client to the member list of that group. In case there is no existing related group for this client, the server will create a new group. The description above is about data structure of the server program. Fig. 4 represents the flow chat of the server program. The flow control of the server program consists of two parts: the command interpreter and the communication control program. which deals with the events of all the objects. Whenever a client makes a call to the server, the listening-socket object will accept the call and create a client-

207

Fig. 4. The flow chart for the server program.

socket object as well. After that, the client-socket object will keep the connection with the client and deal with the client’s request. When a client-socket object receives a package from its client, it will interpret the package and reset the communication status or deliver the package to the other clients according to the client’s request. The communication-management commands, which can be recognized by the interpreter are listed as follows: Users, Groups, Log in, and Router. The commands “Users” and “Groups” can be used to obtain information about users and groups related to this server. The “Log in” command following the parameters “group name” and “client name” makes a client register into the server with the group name and the client name. The Command “Router” initiates the server to create a socket for setting up a connection with another server. The name and port of the server to be connected must be provided after the command “Router”. When clients request “Router” service, the server create a bridge socket. The socket not only works like a common client, but also is able to carry out other special tasks. These tasks include helping its owner to connect to the other servers, returning packages back to the owner, and transferring packages among the group members related to the owner client. Besides the functions described above, the server can also provide the simple services of database accessing. The services include database reading, writing, and records listing. If there is any other database provided by the another application, the server can deliver the client’s request to that application and transfer data back to the client. V. APPLICATION By using this server, we set up an Internet-based telemonitoring system with the architecture, as shown in Fig. 5. The purpose of such a telemonitoring system is to provide a remote monitoring service to the patients at home. The monitoring device at home consists of an IBM PC 486-compatible computer, a modem, a wireless electrocardiograph (ECG) detector, and a blood pressure watch [8]. The ECG and blood pressure data will be sent to the specialist either in the hospital or in a private office (maybe to the doctor at home, the monitor is shown in Fig. 5) through a communication server developed in this work. By making use of this communication server, it is easier to manage the data flow. For example, the server can make an automatic data transferring to the monitor with a doctor on duty. It can also distribute the data to numbers of monitors for advice as well as to save the data in different devices. An IBM PC 586-compatible computer is adopted as the server. The operating system used is Windows ‘95. By running monitoring program, it can also work as a monitoring terminal at the same time while playing the rule of a communication server.

208


Fig. 5. The block diagram of the communication server based telemonitoring system.

Fig. 7. Comparison of the communication flow without and with the communication server in a telemonitoring process.

Fig. 8. The diagram of the dual server structure for teleconference application. Fig. 6. The structure of the monitoring program.

Based on this communication-server-involved structure, a PCbased monitoring center is developed for demonstration. The monitoring center has two functions. One is to accept the messages from the medical specialist and to send them to the server with the requested format. The other is to receive and display the data packages delivered from the server. According to this specified application situation, the display area has been divided into three parts: the graphics area, the text area, and the dialog area. The graphics area is used to display ECG waveforms and blood pressure data. The text area is used to display the text information delivered by the server. The dialog area consists of an edit box and a group of buttons that are designed for the purpose of dialog control, such as to accept messages or to control message-sending direction. The structure of this communication server based telemonitor is described in Fig. 6. The respected patient client program for this telemonitoring system also has two functions. One is to acquire the data of the patient as well as to send it to the server with the higher order byte of the Flag Word in the data package taking the value of one. As defined in our communication protocol, the data package will be delivered to all the specialists in the same group by the server. The second function is to receive and display the messages sent by the medical specialist. In this application, all three communication modes can be demonstrated. The preliminary testing result has shown the feasibility of using the communication server architecture in telemedicine application. The server provides overall management and control of the communication processes in telemedicine applications and has the potential to improve the efficiency by realizing optimal management for various application requests.

VI. DISCUSSION The medical communication server established in this work is able to provide the information communication services for the telemedicine applications. By making use of such a server, the management and traffic control of the telecommunication processes will be simplified. Although the bridge or router devices can also provide the automatic transferring of the data to its identified destination, it cannot play the same rule as the communication server, that is, it cannot decrease the communication traffic load. For example, in the cases of dynamic telemonitoring and medical teleconference, the server provides a simple solution.

For the application of dynamic monitoring, all medical specialists involved can register into the communication server as one working group. The members of this working group can be updated according to the schedule and availability of the specialists without the awareness of the patients. Whenever there is a data package from the home patient to the server, it will be automatically distributed to all doctors in the working group according to the protocol without any extra effort by the patient. The communication logical difference is compared in Fig. 7. Without the service of the communication server, each patient has to know where to send their data and may have to send the data to more than one specialist. With the help of the communication server, the patient only needs to transfer his data package to the server with the appending two-byte address and operation code. The development of such a communication server will make it possible to use a PC as a monitoring center instead of the SUN workstation used previously in the ECG and blood pressure telemonitoring system developed in our previous work [8]–[10]. The server is able to distribute the tasks for the previous monitoring center to distributed devices, as shown by Fig. 5. For example, the server can send all patients data directly to the recorder and to the monitor in the same time. Thus, the monitoring center does not need to control the recorder for the data storage while performing the display tasks. Therefore, a PC is qualified for the monitoring center tasks. This provides a cost-effective solution for the architecture of the telemonitoring system. The PC-based ECG and blood pressure telemonitoring system has been tested and compared with our previous workstation-based system. Results show that there are three advantages to using a communication-server-based system: 1) the tasks of the monitoring center are simplified and distributed; 2) the communication efficiency is increased; and 3) the communication traffic load is decreased. For the application of medical conference, all the participants logged in to the same group are connected by the server. They can send data packages to the server, their group, other clients, or other groups by sending the data packages with different flags to the server. Because the server does not check the contents of the data packages, the client program can send information in the form of text, graphics, image, digital voice, etc. If any of the specialists wants to refer to the relayed information, they are able to read the database of the server. A medical teleconference may be held between two medical centers, for example, centers A and B. If we only setup one server in the center A, the participants in center B must connect to center A.


Thus, the physical communication channel between center A and center B will be very crowded. But if we setup two servers, as presented in Fig. 8, the two servers will be connected with each other by a bridge socket, and the communication will be improved. When using the communication server, the medical teleconference may be held according to the following steps. First, the conference is initiated by one of the participants, for example, the client A1. Client A1 has to log into “Server A” as “Group A, Client A1,” setup a bridge to the “Server B” by using the command “Router,” and log in “Server B” as “Group B, Client B0” through the bridge. After that, the other participants log in as the member of Group A or B according to their local connection. When A1 sends data to “Group A,” the bridge passes the package to “Group B” just like the case of a package sent by client B0. If a client of “Group B,” such as B3, sends a package to “Group B,” the bridge can also pass the package to “Group A.” The reason for this result is that the clients of Group “A” and “B” are joined together through client A1. Such a double server structure for the teleconference application provides a solution for the smoothing communication between two medical centers. By using the double server structure, the communication between two local groups will be managed through the bridge between the two servers. As a results of the double servers management, any of the messages to be distributed among the two groups will only pass the bridge once and then be distributed by the local server.

209

REFERENCES [1] G. W. Brauer, “Telehealth: The delayed revolution in health care,” Medical Progress Through Technology, vol. 18, pp. 151–163, 1992. [2] I. E. G. Richardson, M. J. Riley, W. Haston, and I. Armstrong, “Telemedicine and teleconferencing: The SAVIOUR project,” Comput. Contr. Eng. J., pp. 21–26, Feb. 1996. [3] S. Akselsoon, “Telemedicine and ISDN,” IEEE Commun. Mag., pp. 46–51, Jan. 1993. [4] H. Murakami, “Telemedicine using mobile satellite communication,” IEEE Trans. Biomed. Eng., vol. 41, pp. 488–497, May 1994. [5] E. J. Gomez, F. del Pozo, J. A. Quiles, M. T. Arredondo, H. Rahms, and M. Sanz, “A telemedicine system for remote cooperative medical imaging diagnosis,” Comput. Meth. Programs Biomed., vol. 49, pp. 37–48, 1996. [6] D. Lymberopoulos, “An homogeneous medical tele-working domain supported by a new remote expert consultation conferencing service,” Eur. Trans. Telecommun. Rel. Technol., vol. 5, no. 4, pp. 495–507, July/Aug. 1994. [7] H. J. Stuttgen, “Network evolution and multimedia communication,” IEEE Multimedia, pp. 42–50, Fall 1995. [8] J. Bai, Y. Zhang, B. Dai, Z. Zhu, Z. Cui, J. Lin, J. Zhang, D. Shen, S. Yao, S. Cu, and D. Ye, “The design and preliminary evaluation of a home electrocardiography and blood pressure monitoring network,” J. Telemed. Telecare, vol. 2, pp. 100–106, 1996. [9] J. Bai and Y. Zhang, “ECG and BP monitoring network for home health care,” Int. Med. Devices, vol. 2, pp. 42–44, 1996. [10] Y. Zhang, J. Bai, X. Zhou, B. Dai, Z. Cui, J. Lin, C. Ding, P. Zhang, B. Yu, L. Ye, D. Shen, Z. Zhu, J. Zhang, D. Ye, and L. Zhou, “First trial of home ECG and blood pressure telemonitoring system in Macau,” Telemed. J., vol. 3, pp. 67–72, 1997.