1. Introduction

Robots have unsurpassed contributions in our daily life. They have helped in many dangerous missions like exploring a level 7 nuclear power plant disaster in Fukushima Dai-ichi[1] and scouting for insurgents from the sky in Iraq[2,3], in hard to reach areas like urban gas pipelines[4] and also in mundane tasks like surface polishing[5]. In medicine, robots were given important roles as early as 1960 but faced with many challenges due to issues like safety, precision and cost[6]; even so robots have been part of many medical and healthcare areas: surgery, rehabilitation, human body research, replacing lost body functions, personal care and health promotion[7].

The accommodation of robotic and ICT systems in medical and healthcare discipline is due to several reasons like lack of medical personnel due to large aging population, better diagnostic capabilities, lower cost and improved overall quality. Medical robots currently in service are surgical robots[8,9], tele-presence robots[10] and rehabilitation robots[11]. Besides that, robots have also been developed for assisting in radiotherapy[12,13], rehabilitation therapy[14], as well as dispensing drugs[15] in medical centers. Surgical robots are developed to assist surgeons in different medical procedures, such as laparoscopic surgery[16], orthopedic surgery[17], neurosurgery[18], and tele-surgery[19]. The use of these robots has helped to improve precision, reduce incision size, quicken healing time and minimize blood loss, thus patients will experience less post-operative pain, smaller scar and shorter hospital stay[20]. The other type of health care robot widely used in medical field is tele-presence robot. These robots allow doctors to perform monitoring, consultation and rounding remotely to different locations without the need for transportation.

Remote presence, tele-presence, distant presence, virtual presence and surrogate presence are the common terms for an infrastructure capable of representing or act in behalf of others from a distance[21]. Robotic tele-presence as described by[10] provides the perception of being there or “virtually there” by allowing the users to see, talk, hear and interact thru audiovisual communication on a robotic omnidirectional mobile base. These robots are deployed in places such as museum, trade fairs, office buildings, hospitals and department stores[22]. When these similar technologies are deployed in a medical centers, it can offer healthcare to secluded areas, reduce cost by eliminating the need for transportation and provide aid in solving problems related to patient care in densely populated centers[23]. This is essentially needed by developing countries to overcome the lack of medical experts. InTouch Health’s RP-7 is a common example of commercialized medical tele-presence robot used in developed countries like United States[10]. Unlike regular tele-presence robots, it has medical functionalities and able to interface with peripheral medical instruments. However, these systems are too costly for many under-developing nations due to their exorbitant purchase and maintenance cost[24].

Emergency cases such as orthopedic emergency cover about 40% of the cases in Accident and Emergency Department of a hospital. Often these cases are hard to diagnose and handle without the help of a qualified specialist[25]. Consultations with other experts may be needed depending on the experience, the expertise and the confidence of the doctor in charge of the case. In addition, the personnel present at that instance may not qualify in managing that particular case. These may lead to life-threatening complications if proper and immediate treatments are not accessible. E-health systems like EMOSNet[26] and TeleOrthPaedics[25] are useful to provide adequate preparation time for the surgical unit before the arrival of the patient and reduce the possibility of sending patient to the wrong medical center due to insufficient case information.

However, the existing e-health systems including EMOSNet and TeleOrthPaedics do not have robotic tele-presence capability, which gives the doctors real-time interaction with their patients. Besides being too pricey for developing countries, current robotic tele-presence systems such as RP-7[10] are only designed for tele-rounding purpose rather than attending patients in emergency situations. Therefore, a specialized robotic system with flexible vision system for diagnosis and medical instruments to obtain vital signs of the patient is developed specifically for emergency and rounding routines. Medical Tele-diagnosis Robot or MTR is a mobile robot equipped with basic medical instruments, including sphygmomanometer, Pulse Oximeter, Vascular Doppler and X-ray scanner for real-time diagnosis. It is also fitted with two video cameras: diagnosis camera and navigation camera. The diagnosis camera is oriented and positioned with the help of a flexible robotic arm.

The structure, requirement and functionality of MTR introduce new challenges to the design of its communication and control platform. First, a specialized network mechanism must be designed to operate on low capacity networks to make the system affordable for developing countries. This is because high capacity network translates to high maintenance and high setup costs. Second, a specialized video encoding and decoding module must be developed to encode two real-time medical video streams as these functions require significant computation and network resources. Third, a simple and low cost robot to network interface must be developed to provide network access to the robot.

2. The System

The system proposed by this research intends to work with Medical Tele-diagnosis Robot (MTR) equipped with basic medical instruments to allow specialists or doctors diagnose patients remotely via regular broadband internet(Figure 1). In addition, this robot is also equipped with a non-interventional flexible robotic arm to position and orientate the diagnosis camera (a high-resolution video camera). This feature is especially useful for diagnosing patients in cases similar to orthopedic emergencies. The robot has a holonomic mobile base as a means of locomotion. The holonomic drive gives the robot an easier maneuvering. Also, the platform developed by this research must interface with the robot controller boards to control the robotic actuators and obtain readings from the onboard sensors located around the robot.

The development of the system described by this research is separated into network engine, audio-visualsystem, robot-computer interfacing, medical information management and robot control interface.

Figure 1. Medical Tele-diagnosis Robot

2.1. MTR Network

MTR Network incorporates P2P overlay technology to create a unique self-scaling architecture where an increase of participation increases the capacity of the system, thus it is capable of providing certain types of services at a cost level unachievable by client/server architectures[27] especially on services that need extensive network bandwidth, storage and computation. This is done by sharing the cost of operating the overlay with every end user hence lowering down the hardware and network investment needed to launch the infrastructure.P2P overlay may sound perfect and attractive theoretically, however the lack of security features in pure P2P networks is making them vulnerable to security attacks that are meant to disrupt, intercept and corrupt the functions of their systems. Pure P2P network is also extremely dependent on peer behaviors (churn-rate, the ratio of contribution/consumption and rogue peers), which influence the quality of the infrastructure. To overcome the downside of a common P2P overlay, MTR Network uses hybrid P2P network which incorporates both centralized and decentralized architecture. This architecture provides peer access control on the overlay thru central servers. With these servers, the network is capable of granting and revoking access permission of each peer. Besides that, local dedicated servers are incorporated into P2P groups to store and host files consistently even when no seeding peer available.

Figure 2. MTR network

The MTR P2P overlay is intended to provide three types of functions, communication between Control Station and Robot, sharing of patients’ medical data and multicasting of the tele-diagnosis session to the intended audiences. During the communication between Control Station and Robot, robot control messages, audiovisual stream and patient’s real-time medical information are exchanged between these end points via a direct adjacent P2P link. As for medical record sharing, stored medical data such as blood pressure, radiograph image and blood oxygen saturation are not only kept in local hospital servers but have copies distributed and stored in nodes or peers that had accessed or participated in cooperative storage to improve the infrastructure’s performance by sharing the load of the system with the peers. MTR’s hybrid P2P overlay also provides overlay multicasting for third person viewing on any tele-diagnosis session without subjecting any interference to the actual process. Here, overlay multicasting is used in place of more efficient native IP multicasting because of current limited IP multicast support by the ISP due to its high implementation cost[28]. Figure 2 shows the simplified MTR network.

The MTR’s P2P overlay is developed on Microsoft’s Peer Infrastructure. Starting from Microsoft Windows XP SP 1, Windows operating systems have included support for fully decentralized P2P network that is based on Peer Name Resolution Protocol (PNRP). It is made accessible to developers via Peer Infrastructure APIs. Based on fully decentralized architecture, PNRP requires neither a central server for peer discovery nor a server-based Distributed Name Service (DNS) to resolve hostnames to IP addresses. PNRP is developed by Microsoft to address the scaling problems that persist in common P2P networks such as Gnutella and Freenet when working in large-internet-scale networks[29].

Microsoft’s Peer Infrastructure by default supports secured communication services. One of the most useful features provided by Peer Infrastructure is Peer Grouping. This function allows this research to enforce privacy and security in communication and data sharing between peers in the group. It also permits each group to have its own secured unique ID, administrators, Group Membership Certificate (GMC) and Group Root Certificate (GRC). Through that, the Grouping function can manage the permissions and access rights of the peers to protect shared data objects from unauthorized modifications. As for group membership management, group administrators are assigned to create invitations for new members and revoke existing memberships. Similarly, administrators are able to delete and modify data shared by other peers for data content control. Figure 3 shows the overall structure of Peer Infrastructure.

Figure 3. Windows Peer Infrastructure

The MTR’s Network is a multilayer P2P overlay (Figure 4). The lowest layer of the overlay is the server-less layer where PNRP engine maintains the peer cloud. The second layer consists of the graphing layer that manages the low level data communication between the nodes. The next layers are conceptual layers based on overlapping peer groups (Figure 5) to maintain privacy, share information with the target audiences, simplify the setting up of a private service, increase efficiency of the peer overlay, and delegate administrative tasks to trusted peers instead of depending only on the server. It is named as mentioned because the overlay can be visualized as layers of groups encapsulating and overlapping each other depending on group’s service or role. These overlapping groups represent access permission and also the actual participation of the peers. This means a peer that has access (membership) to a subgroup will also be able to access the parent-group. All these are developed with Peer Infrastructure’s Grouping API due to its simplicity. This network architecture (based on groups) can quickly adopt the security features provided by Peer Infrastructure’s Grouping API. Also, with the Grouping API, this research can omit: designing step of PNRP procedures, development of security service provider and the need to deal with low-level Graphing functions. Besides for enforcing access and privacy control on the overlay, the grouping concept maintains the efficiency of the overlay by limiting the information broadcasting size thus, reducing message flooding overhead incurred during searches, queries and synchronization procedures.

Figure 4. Layers in MTR Network

Figure 5. Visualization of MTR Network Overlay in conceptual layer

Before any peer can participate in the overlay, it must first undergo user authentication procedure in login step. During login, the following procedure is used:

1. Client connects to the Central Server and attempts authentication.

2. If successful, a public group GMC is created under the client’s Peer Identity.

3. The GMC is then issued to the client together with the public group invitation.

4. The client joins the public group with the GMC and invitation received.

Following the login process, the client is placed as a peer in the public group which is the overlay’s base group and universal public group located in ‘Global’ PNRP cloud where all certified MTR Network peers join when they completed the login procedure. At here, all the peers are able to communicate with each other and the server securely for: group invitation distribution, peer status discovery, private dialog between peers, and administrative tasks by the server.

Then, for the peer to start working in a private group, it must choose one of the following tasks, create, join or open a private group. A new private group is created in several occasions such as, creation of temporary service, in an MTR tele-diagnosis session, and creation of permanent service, when a new department in medical center is established. Peers in the public group can also choose to join the existing private groups with their valid invitations. However, a peer can open a private group if the group was previously joined or created by it. By opening a private group, the peer can skip the login procedure which involves the Central Server. This is done via the previously stored Peer Identity and GMC in the local computer if the peer did not log out from the last group session. Similarly, the public group can be access without the login procedure if the peer (client) had not logged out. When clients log out, their security information (GMC and Peer Identity) stored in the computer will be deleted to prevent unauthorized impersonation of the user.

2.2. Audio-visual System

Audiovisual System plays a very important role in MTR because it handles the core functionality of the system – visual (video) and audio (voice) communication for doctors, patients and nurses in (1) diagnosis, (2) discussion and exchanging of ideas between medical personnel and (3) coordinating a medical procedure. For this, it is very important to assure that the proposed system for this research suits the application and needs.

Firstly, MTR requires two different cameras to operate at the same time during a tele-presence (tele-diagnosis) session because it requires complex positioning of camera to capture an accurate image on the region of interest. For this, a high-resolution camera is mounted on a multi-degree-of-freedom robotic arm to position and orientate the camera, giving the viewer at the Control Station a clear real-time image on the body part. Since the high-resolution camera is already occupied for medical diagnosis, it is necessary to have another lower resolution camera to provide the doctor at the Control Station eye contact with the person he or she is communicating. The same lower resolution camera is also used as feedback during the navigation of Robot.

The MTR’s audiovisual system is developed based on Microsoft Media Foundation platform that is shipped together with Windows operating system since Windows Vista. Media Foundation is designed by Microsoft to replace deprecated DirectShow, Windows Media SDK, DirectX Media Objects (DMOs), Audio Compression Manager (ACM) and Video for Windows (VfW) for Windows with extra support for Windows Media Center. Media Foundation is used in the development of MTR because it provides support to newer media types like ASF, and flexibility in designing the system so many components such as media source, media foundation transform and media sink are customizable by creating a custom plugin.

H.264 video encoding scheme has a good quality to bitrate ratio but has significant encoding and decoding complexity that may incur latencies, which are intolerable in real-time applications. Here, with the flexibility of Media Foundation, the multipurpose parallel computation technology of a modern GPU, such as Nvidia’s Compute Unified Device Architecture (CUDA) can be incorporated to greatly suppress the latencies generated from video encoding and decoding, and to offload the main CPU for other important tasks. Therefore it is necessary to incorporate CUDA in the design of MTR’s video codec especially in Robot’s onboard computer because large video encoding latency may toughen the control of the robot as video is the primary control feedback. Huge encoding latency may also affect the diagnosis process.

2.3. Robot-computer Interfacing

This section will discuss the design of Robot-computer Interfacing module, one of the core components in Robot which connects the robotic hardware to the onboard computer. This module transfers control messages from the onboard computer to the peripheral robot controller boards and vice versa. This component is the backbone of the core functionality of this system, including Robot’s locomotion, sensor feedback, flexible arm control, onboard battery level, danger monitoring and data from medical devices. Figure 6 visualize the physical entities needed for the core operation of the robot.

Figure 6. Physical structure of robot-computer interfacing

Robot interface board is assigned to manage, translate and route the control and feedback messages exchanged between the onboard computer and the robotic hardware via Universal Serial Bus (USB). USB is chosen as the means for interfacing due to its high speed, widely adopted standard, plug-and-play capability, and its simplicity compared to conventional PCI, RS232 and parallel interfaces. As for the communication between the robot interface board with its peripheral robot controller boards, SPI and I2C busses are used. These two serial communication standards are chosen due to their simplicity, low cost and wide adoption. To implement these features, a single chip USB capable microcontroller is employed as the master for master-slave communication with all the robot controller boards and also the onboard computer.

Figure 7. Physical structure of robot-computer interfacing

This research uses Microchip’s PIC18F4550 as the microcontroller for the interface board. PIC18F4550 is an 8-bit CMOS FLASH programmable microcontroller with 2048 bytes SRAM, 256 byte EEPROM, four timer modules, nanoWatt Technology, two-pin In-Circuit Serial Programming (ICSP), two-pin In-Circuit Debug (ICD), 10-bit 13-channel analog-to-digital converter module, two capture/compare/PWM (CCP) modules, Enhanced USART module and dual analog comparators.

2.4. Medical Information Management

Medical Information Management handles the storage, retrieval, presentation, creation, indexing, sharing and transmission of patient medical data using the P2P functionality supplied by the network engine. This component is shared by all the client entities in the network including robot, control station, local server and regular client, where in each entity, it has slightly different functionality.

Medical data can be created or generated by three system entities – robot, control station and regular client. The medical data generated by Robot are radiograph images, blood pressure, pulse oximetry, and Vascular Doppler readings, and audio-video stream for real-time transmission to control station. These information are also transmitted to spectating clients and other participating clients at near real-time. To ensure timeliness of the medical data transmission from robot to control station, secured direct connection is used. As for control station, medical records, prescriptions and orders are written and updated by the physician digitally and transmitted to Robot via secured direct connection. These written documents are also stored distributedly in the private group (in peers). Figure 8 shows the robotic tele-diagnosis process.

Figure 8. Medical data creation and real-time transmission

This research adopts distributed file storage mechanism for storing, sharing and indexing medical records. It is done using the existing functions supported by the network engine. This storage mechanism is intended to offload the file server facility, thus minimizing the need for more powerful machines and network to cope with the growing number of users. Besides that, this system overcomes the single point of failure problem that normally occur in common client-server systems.

Since the information storage system relies mainly on distributed architecture, the privacy and security of the system must be the main priority of the design. This is because private health information is stored distributedly in anonymous group members (peers) where it is vulnerable to unauthorized disclosure, altering and sabotaging of important information. Also, the design of the system must also maintain the cost-effectiveness and self-scalability while distributing and retrieving medical data to group members in storage and retrieval processes. To improve cost-effectiveness, segmented data distribution mechanism is used since, the transfer of medical data is usually one to many (multicasting). For these purposes, a specialized storage system must be designed to store the medical records in encrypted form, secure the encryption key, transfer medical data between multiple to multiple peers and index the stored medical records.

First, there are two main data components in this system, patient data index and shared medical data. Patient data index is a table of records linking shared medical data IDs and their details (timestamp, size, friendly name and etc.) to patients’ records that are stored in group records database. Shared medical data are encrypted files or data chunks stored in the peer group overlay. Figure9 illustrates the simplified operation for medical data storage, indexing and sharing. The distributed storage process is as follows:

1. The medical data created is encrypted with a random symmetric key generated by the source node

2. The content of medical file is distributed to all the participating peers.

3. The encrypted data block is registered to patient data index under the respective patient’s record with its specific ID, data details and encryption key.

4. The encrypted medical data block is shared with other peers by distributing to them.

Figure 9. Overview of health information storage process

As for the medical record retrieval process (Figure10), client’s access to medical data adopts the following process:

1. The client joints the private group.

2. It then searches for the patient’s record located at patient data index and retrieve the file ID, details and security key corresponding to the data it intended to access.

3. On successful retrieval of the file information, the client proceeds with file downloading.

4. Finally, it decrypts the downloaded file with the security key.

Figure 10. Overview of medical data retrieval process

2.5. Remote Robot Control Interface

Remote robot control interface (Figure 11) is designated for controlling Robot remotely thru Control Station. At Robot’s side, it links with robot interface software to obtain proximity sensors, inclinometers and digital compass readings that will be transmitted to Control Station. From the proximity sensors’ values obtained, Robot Control Interface then maps it to Robot Program GUI panel to display obstacles in Robots surrounding. Inclinometers readings will also be shown in Robot Program GUI to display ground inclination to prevent Robot from toppling while navigating the robot. Similarly, digital compass reading will be displayed to provide navigational guide. Robot Control Interface feeds the Robot-computer Interfacing component with control command received from Control Station thru MTR Network. At Control Station’s side, this component interfaces with a joystick to receive user input for controlling Robot. The joystick input is then interpreted and transmitted to Robot over MTR Network. Proximity sensors, inclinometers and digital compass readings received via MTR Network is displayed on Control Station Program GUI in similar layout to Robot’s side to give the operator information on Robot’s surrounding for easier, faster and safer Robot operation.

Figure 11. Overview of medical data retrieval process

3. Experimental Results

This section discusses the analysis, testing and experiment to gauge the design proposed by this research. Here, the critical components of MTR System will be tested for different criteria depending on their functions and purposes. The subsystems or components involved are, MTR Network, audiovisual system, Robot Control Interface and Medical Information Management. All these subsystems will be tested together at their normal operating conditions in a controlled environment to understand their behaviours, capacities and constraints.

Figure 12. Round-trip test result

Figure 13. Delay variation test result

Figure 14. Throughput test result

3.1. Network Behavior

This experiment is concentrating primarily on its proposed P2P engine to analyze its basic service metrics for throughput, jitter and delay. These characteristics are important in determining the reliability, quality and usability of the overall system especially in its robotic tele-diagnosis function. Figure 12, Figure 13 and Figure 14 are graphs derived from the experimental results. Referring to Figure 12 and Figure 14, the network is shown to possess similar RTT and data throughput characteristics to plain TCP for different data-rate and payload sizes but with small amount of delay and bandwidth overheads. These small fluctuating overheads observed in P2P tests may be caused by the PNRP control messages transmitted and received in the background to maintain the P2P graph. However, the larger component of these overheads are possibly caused by Grouping API’s security overhead. In Figure 13 both P2P and TCP tests have shown fluctuation in round-trip-time which can be equated as delay variation. By comparing the standard deviation graphs, P2P test has generally shown higher total delay variation than TCP. This effect possibly caused by Grouping security overhead.

3.2. AudiovisualPerformance

This test aims to measure the end-to-end delay of the video streams received in Robot, Control Station and Regular Client.During the test, all the other components such as Medical Information Management and Robot-computer Interface are fully operational to simulate the complete MTR system. MTR’s RTD routine are simulated for 900 seconds each, generating 9000, 22500 and 18000 delay results for diagnosis video, navigation video and doctor video respectively. The test results are tabulated in Table 1. The tested video streams shown in Table 1 have delays lower than the recommended delay of 250ms for mission-critical telerobotic control mentioned in[30]. From the test results acquired for diagnosis and navigation videos, it is observed that the use of CUDA video decoders produces lower decoding delays than software decoders, which resulted in smaller end-to-end delays. The test results produced by doctor video have shown that CUDA encoders could reduce the encoding delays significantly, thus lowering the overall end-to-end delay of the video stream.

Table 1. Audiovisualdelay results in MTR’s RTD routine Video Codec Type Result Robot Control Station Mean End-to-end Delay Diagnosis CUDA Software 208.362 ms CUDA CUDA 202.487 ms Navigation CUDA Software 158.452 ms CUDA CUDA 153.441 ms Doctor Software CUDA 157.011 ms CUDA CUDA 109.710 ms

3.3. Remote Robot Control Performance

This subsection tests the performance of the robot control function. The performance of the robot control function determines the safety, reliability and controllability of the Robot. During the test, the joystick at Control Station is randomly triggered to produce random control commands at random rates for 15 minutes. The computed respond delay values are then recorded to calculate its mean and delay variation. Table 2 shows the summarized results obtained from this test.The results obtained in this test have shown that MTR has an acceptable delay for a long distance robotic control. The delay is smaller than maximum tolerable delay for very critical missions including telesurgery that allows delays until 330 milliseconds for a safe operation[31].

Table 2. Robot Control Delay Mean Delay Min Delay Variation 192.784ms 18.851ms

Figure 15. File storage transfer rate

Figure 16. File retrieval transfer rate

3.4. MIM Data Storage and Retrieval Performance

This section tests the feasibility and performance of the proposed distributed storage system in MIM on real-life scale, which involves large number of nodes. However, the cost for testing full-scale MTR’s P2P overlay is high because large number of peers (Regular Clients, Robots, Control Stations and Local Servers) is needed. Moreover, large P2P network is hard to test and coordinate in real-life because their test parameters and outcomes are spread across the network, thus hard to control and determine. Hence, in this research, software simulations are used to estimate the effectiveness of the MIM system proposed in this research instead of an actual test. This test uses open-source simulation software, OverSim to estimate the characteristics of MIM at different scale. The results of the simulations are presented in Figure 15 and Figure 16.

From Figure 15 and Figure 16, it is observed that both storage and retrieval transfer rates of MIM are not affected by the increase of peer/client count, whereas, the transfer rates of the client-server setup have dropped exponentially when the client count increases over the server’s capacity. The MIM shows this characteristic because it exploits P2P’s self-scaling capability and limits the size of the P2P graph thru grouping. Large ungrouped P2P graphs have large communication overheads due to inefficiencies in broadcasting mechanisms like flooding.

4. Conclusions

In this paper, a communication and control platform for Medical Tele-diagnosis Robotis presented. It consists of a peer-to-peer based network, audio-video communication module, robot-computer interfacing device, distributed medical information storage and retrieval system and remote robot control interface. The complete system was tested and simulated and was proven feasible.