In major medical centers, teleconferences have also become ... teleconference would be the ideal way to manipulate ... light enough to do not impose prohibitive.
Application Protocol for a DICOM Real Time Collaborative System Abdala, D. D., Prusse, M., Regert, A. G., Wangenheim, A. v. February 2006 {caju, martin, germano, awangenh}@inf.ufsc.br The Cyclops Project Laboratory of Telemedicine (LAB TELEMED) Computer Science and Statistics Department (INE) Universidade Federal de Santa Catarina (UFSC) Florianópolis – Santa Catarina – Brazil Phone: +55 48 3331-9516 Fax: +55 48 331-39516
Abstract This work presents a new generic application protocol for DICOM conformant medical collaborative systems. It implements simple techniques for data flow and encapsulation between two or more clients and a single server, using an extension of the DICOM Communication Layer within a server or a client as a session manager. The protocol was tested working over two image viewer clients remotely distributed and the synchronization level shows that collaborative systems can be executed in real time.
1. Introduction It is becoming increasingly common to use Digital Imaging and Communications in Medicine – DICOM [1] – compliant software and equipment in healthcare institutions, mostly Picture Archiving Communication Systems – PACS – to retrieve, store and transmit patient-related information. In major medical centers, teleconferences have also become routine, enabling specialist physicians to employ their time more efficiently. However, the technology commonly used was not developed with this specific purpose in mind (i.e. videoconference stream using standard definition television does not seem to be the best way to analyze a magnetic resonance image and confirm findings). In this sense, video conferencing is an efficient but limited system, only providing actuation on the exam in the client viewer where it is being shot and being extremely limited in image resolution and accuracy. To circumvent this issue, a direct shared view of the image information in scope on the teleconference would be the ideal way to manipulate it, and thus enable actions on both ends of the line to be carried out. This would provide a collaborative
system scenario with real time interaction. Unfortunately, the direct share view of medical imaging data can not be achieved using only the protocol services provided by the DICOM standard, since it is not concerned in application specific requirements. Commercial solutions available for this purpose have proprietary protocols, making difficult the intercommunication between different software. Provide a new application protocol at the same time, simple to use and implement, to work embedded in DICOM compliant applications and light enough to do not impose prohibitive network bandwidth constraints is the main reason of the presented work. The protocol described in this paper aims the real time data application information sharing, where the exchange of application states, image data, presentation states video streams and synchronization between hosts can be achieved with no changing in the DICOM network services.
2. Problem Description Imagine that a difficult exam must be examined by a physician and the one in charge feels that he is not capable to give a final word. It is ethical to say that in such cases another physician must be consulted in aid to his fellow, since a diagnosis must be precise. These specialists can not meet each other so easily, so the final diagnosis must be delayed. Using a computer tool that works in a collaborative way, both physicians can quickly be in a virtual meeting and discuss the case as soon as possible, aiding considerably to speed up the process. The application protocol that we present here is intended to aid medical image viewers to be put easily to work together. This
way, all tools provided by this branch of software can be at hand to facilitate even more the physicians’ job. Enabling the suggestion of an application protocol that works over the DICOM network services and with the main objective of encapsulate the data sharing between the digital diagnosis tools can make it possible. It is possible to find similarities to HL7 [2] protocols, which aims to intercommunicate and integrate all software in a medical environment, but not aiming the real time collaboration between applications. This research describes an application protocol for a real time collaborative system, meaning direct interaction at a user level. A proposal of how to generically map the resources of client software of different brands and sync them directly between other clients will also be shown here.
3. Material & Methods An Upper Layer Service – UL Service – was configured in the Laboratory of Telemedicine [3] within the Polydoro Ernani de São Tiago University Hospital as a test environment for this generic application protocol. A Cyclops DICOM Server [4] was used for examination storage. One client was installed with the Cyclops Medical Station – CMS [5] – plus an actual implementation of our protocol, a software called in Portuguese Sala de Laudos Virtual – SLV [6]. Another client with the same specifications was installed at a partner private clinic. The Telemedicine Lab has a high speed internet connection and the client installed at the partner clinic has a broadband link with only 600kbps download and 300kbps upload, reflecting the reality for most small clinics in Brazil. The CMS is a robust client for accessing DICOM repositories, visualizing radiological images, and realizing fast and efficient findings. SLV is an interface operating with the protocol, encapsulating some of the CMS capabilities. Specifically, it captures the changes on the medical information from the examinations opened on CMS, interprets the data and then instructs the other clients in session on how to reproduce them. This does not encompass all the capabilities of the protocol. All data in repositories have similar characteristics. Most clients have tools for changing, or at least reading them. The basic characteristic of our protocol is that it allows manipulation of an attribute in the medical data in question for all clients in the session, leaving the task of server as only a manager until all the changes are done.
This is made possible as a result of the common characteristics shared between the DICOM data and its Information Object Definition – IOD [7]. The function of our new application protocol is to capture the data to be manipulated and send this information over the network directly to an interested party. “For most multimedia applications, the QoS performance measure in the application layer is actually a subjective one based on human perception… applications such as medical images for remote diagnosis demand extremely reliable information delivery.”[8] The UL Service base stack is the popular TPC/IP [9, 10 11. Through a simple broadband connection, a physician should be able to, using a simple DICOM viewer, access examinations from a remote location on the clinic server, and should be capable of updating the server database with new examinations. It would also be useful to enable a physician to review his appointments for the next day using a workflow client. This method of communication already exists at an OSI [12] protocol association level on the UL Service. It is used by DICOM compliant software and is controlled by servers that have control over what host is able to access what data, such as retrieval of examinations. Presently direct interaction between clients exists only in proprietary protocols and therefore limits their use to those sections of the market that use such proprietary software. The primary objective of this research is to obtain direct client interaction at an application level independent of proprietary brand through the creation of an application protocol that aims to establish common tools and generic modifications which may be applied to radiological examinations. The developed application protocol is divided in three layers: one for control, where Network traffic is done through a generic TCP/IP interface; the second for DICOM data manipulation interception and encapsulation; and a third one for communication between users. A tagging system is responsible for the identification of control, data and communication packets. Simply put, each time new kinds of information are added to the collaborative session context, a new tag is determined for that information. This way, manipulation of data can be made in real-time and is shared with all involved parties.
Before any data can be transmitted, a TCP/IP channel is established. This can be done through a server or directly between clients. For easier understanding, a direct connection between clients will be described next.
S-CWAIT S-CCONNECT S-CCONSUCCESS S-TAG-WAIT
3.1. Connection and Session creation
S-TAG-REQ
To directly connect two clients with the proposed protocol the well known client-server architecture is utilized with one host acting as a server. The roles of each client change during session depending on the activities involved. The figure bellow shows a simplified diagram for the connection between two clients, and definition of the first and obligatory tag, a tag for our first layer, control.
S-TAGSUCCESS C-SUCCESS
Fig. 1 – State-diagram for direct connection. Table 1 describes each state in the previous diagram. Table 1 – Actions taken on direct connection. STATE DESCRIPTION q0 No connection established. q1 Waiting for TCP/IP socket connection. q2 Establishing TCP/IP socket connection. q3 Requesting establishment of a new TAG, to use for application protocol control. q4 Waits for new TAG, to use for application protocol control establishment.
Table 2 describes each action in the previous diagram. Table 2 – Actions taken on direct connection. DESCRIPTION The application protocol shall enter wait mode. (this side is the server on the client-server model) C-CONNECT The application protocol shall make the connection (this side is the client on the client-server model)
listen on a TCP/IP port for a connection connects to a TCP/IP socket the TCP/IP socket is open and connected the application protocol waits for a new TAG request the application protocol sends a new TAG request the new TAG has been successfully agreed the application protocol is connected and shall enter in idle mode
3.2. Capabilities Negotiation The capabilities of each host's application are traded after connection time so that what can be done during the collaborative session is defined. For example, it will be possible for both hosts to have the capability to manipulate a Computer Tomography density window. For the tested version of the protocol, a set of the most used IODs were selected with their respective possible operations and manipulations. This list was structured in way a similar negotiation as DICOM Message Service Element – DIMSE [13, 14] – Association Negotiation was possible. The main difference is that the DIMSE association is already done, and the possible operations are negotiated instead. At capabilities negotiation time, the sets of IODs operations are crossed in an intersection of all sets. This new arranged set is the one that will be used during session, and is broadcasted to all hosts through a masking system. Operations not present in one host are masked, as not useable during session in all the others, therefore maximizing the kinds of manipulations possible.
3.3. Message Structure We have two basic package structures on our application protocol. One of them is used on the first layer, the second used on the two other layers. The session package is used for identification of data transmitted in session. Within a session there can be one or more contexts, where a context is defined by a tag.
ACTION C-WAIT
Fig. 2 – Session Package The session package is used for identification
of data transmitted in session. Within a session there can be one or more contexts, where a context is defined by a tag.
FILE_TRANSFER
DISCONNECT
Table 3 – Session Package field description. FIELD DESCRIPTION CTRL This field identifies if the package is used for data transferring or tag establishing. TAG The TAG field contains a tag identifying the context of package data. SIZE SIZE enumerates the number of bytes in the DATA field. DATA Simply the data to be delivered. Normally an Application Packet.
The Application Package is used to trade operations in a determined context. It is structure is described bellow.
Fig. 3 – Application Package. The tree fields of the application package have their functions described on the bellow table. Table 4 – Application Package field description. FIELD DESCRIPTION CMD This field identifies the kind of operation to be executed. These could be manipulation, communication or application control. SUBC The SUBC field identifies the operation to be executed, directly dependent of the CMD field. DATA All data needed by the command and subcommand fields are placed here.
The SUBC field has a different behavior dependent of the CMD field. When CMD defines user textual communication, SUBC must be ignored, since DATA will contain the message text. When CMD identifies a control field, SUBC must have one of the procedures defined in Table 4. Table 5 – Control SUBC field operation. OPERATION DESCRIPTION SESSION_CONTROL Indicates one of the hosts is taking or releasing session control. The DATA field has 0 (zero) bytes. NUMBER_OF_FILES Indicates to the application to prepare for file transfer operation. The DATA field has 4 bytes, containing the number of files to be received or sent.
Indicates file receiving, DATA having information about file name, file size and the file itself. Indicates end of session, and all resources used during it must be released
When CMD identifies as a manipulation field, SUBC will describe one of the tools described on Table 5. Table 6 – Manipulation SUBC field description. FIELD DESCRIPTION GENERIC_TOOLIndicates selection of one of the tools allowed on the negotiation stage. COLOR_TOOL If the tool is a visual tool, a color can be selected. KEY_TOOL Provides real time editing for text tools. MOUSE_TOOL Provides a real time pointing utility. Allowing a host to point an area of interest in the image, as well other real time interactions.
3.4. Session Storage: It is not a function of our protocol to save the manipulation done on the DICOM data during a collaborative session. Thus, if the client which the protocol is running has the ability of saving manipulations to an archive, this would not change because of the protocol.
3.5. Session Close: The closure of a collaborative session does not differ much from the connection. This closure begins when a DISCONNECT message is received by the application protocol. The Tags used during the session should be released and make available for future use. Finally the socket connection is closed.
4. Results and Conclusions During the tests between our clinic partner and our lab in the hospital various difficulties on connection establishment occurred. In most cases, the problem was a miss-configuration of firewalls, like wrong port forwarding between the clients involved. To avoid wrong configuration of firewalls on the address level, a VPN connection was set in the clinic, allowing a private secure connection to the hospital. After solving those issues, the developed protocol has
demonstrated robust behavior. Since it does not affect directly the usability of the client software, user adaptability did not present a problem. Only a few steps have to be added to start a collaborative session. The client software CMS has a radiological workstation scope, so the common use of our protocol in our tests were collaborative findings. If we were to use a streaming video with the common resolution for medical clients, meaning the bigger the best, network resources would be prohibitive. With the clients working on the IOD level, the little information needed to be transported through the network was light enough to be successfully supported by a broadband connection. Manipulation of medical information could be seen occurring simultaneously on both sides of the point to point connection.
5. Future Works This approach to an application protocol and environment is generic enough to support other kinds of applications and also be extended reliably. A definitive solution to the firewalls problem is the development of a collaborative session manager server, a work already in progress. A future work with this protocol would be adding support for virtual reality applications, already in development. Also, a potential function would be loading the data and playing the sequence tags using RTP [15] as a support protocol, to review a collaborative session or stream it over the network to an interested party, such as a congress or radiological classrooms.
6. Acknowledgments We dedicate this paper to our friends on the Telemedicine Lab and our families for their constant love and support.
7. References [1] DICOM Official Website. Available at: Accessed on January 11, 2006. [2] Health Level 7. Available at:
. Accessed on January 22, 2006. [3] Laboratorio de Telemedicina. Available at . Accessed on January 12, 2006. [4] Cyclops DICOM Server. Available at: . Accessed on January 21, 2006. [5] Cyclops Medical Station. Available at . Accessed on January 12, 2006. [6] Sala de Laudos Virtual. Available at . Accessed on January 12, 2006. [7] Digital Imaging and Communications in Medicine (DICOM) - Part 3: Information Object Definitions. Virginia, 2004. Available at: . Accessed on January 11, 2006. [8] Jitae Shin, D. A. Lee, C.-C. Jay Kuo. “Quality of Service for Internet Multimedia”. Prentice Hall. July 24, 2003. [9] J. Postel. “Internet Protocol”. September, 1981. Available at: Accessed on January 12, 2006. [10] T.J. Socolofsky, C.J. Kale. “TCP/IP tutorial”. Available at: . Accessed on January 11, 2006. [11] J. Postel. “Transport Control Protocol”. September, 1981. Available at: Accessed on January 11, 2006. [12] A. S. Tanenbaum. “Computer Networks, Fourth Edition”. Prentice Hall. March 17, 2003. [13] Digital Imaging and Communications in Medicine (DICOM) - Part 7: Message Exchange. Virginia, 2004. Available at: . Accessed on January 11, 2006 [14] Digital Imaging and Communications in Medicine (DICOM) - Part 8: Network Communication Support for Message Exchange. Virginia, 2004. Available at: . Accessed on January 11, 2006. [15] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson. ”RTP: A Transport Protocol for RealTime Applications”. July, 2003. Available at: . Accessed on January 12, 2006.
