Telemedicine: An IoT based Remote Healthcare System

This paper proposes a remote healthcare system which is referred to as Telemedicine. Telemedicine is a platform that estableshes a connection between the patient and the doctor. This platform belongs to the internet of medical things (IoMT) by enabling multiple medical sensors to connect to a server either using multiple communication technologies such as Wi-Fi, Bluetooth or GSM technologies. The system collects data from several sensors and sends them using one of the aforementioned technologies using an Arduino Board, while the interface is made with matlab and C#. Additionally, a comparative study between the three communications technologies used to connect the medical sensors to the server is investigated. And a recommendation of the best suited technology is provided with regard to the nature of the application itself. Keywords—Telemedicine, IoT, IoMT, GSM, RF, Wifi.


Introduction
O According to [1], it is expected that by 2021 that the health market will reach $136.8 billion across the world. However, the adoption of the internet of things (IoT) has been a little slower in healthcare industry more than most of the other industries, The Internet of Medical Things (IoMT) not only assures that the technology will preserve people safety and health, but also reduces healthcare costs over the coming years [1,2].
IoMT was proposed to reduce the effort in monitoring, informing, and notifying patients with updates. Additionally, it can provide doctors with statistics and actual data to be used to identify and understand the sources of medical issues [1,2]. Telemedicine is a relatively new term which is being used intensively as of late. Telemedicine can have many types, some are just used to take a remote advice of a doctor through some kind of messaging platform, some are used to set appointments with doctors, and some are used to detect any abnormalities in the patient's body by the use of special sensors [3].
For the communications part, some fitness and wearable headset applications use Bluetooth [3,4]. Wireless LAN is also an alternative. However, it is considered a power consuming technology when compared to other methods [3,4]. Cellular data such as GPRS is known to have quite a lot of limitations for its slow data rates compared to present day solutions but it still have some use in the healthcare field.

Background and Related Work
Telemedicine started as just the transmission of radiology images in 1940s between two towns which formed the basis for creating the Telemedicine platform [5]. A Canadian scientist worked on the idea on 1950 and created the first sharing hub for the city of Montreal, this later developed into using video conferencing in hospitals for discussing patient's issues as well as remote surgery guidance from experts in the field [5].
One of the things that can enable Telemedicine is the incorporation of the Internet of things which allows remote health monitoring through peripherals you wear much like fitness bands, remote heart rate sensors, and devices that maintain, and send updates on any implanted artificial organs within the human body [3]. Smart beds are now a common occurrence in hospitals which measure the patient vitals while they lay on them and could be used to send alarms in case of emergency as well as adjust the comfort level of the bed without any interaction from the staff. As of the date of this paper, an estimated 300 billion Dollars are spent yearly on medical innovation in the US [3]. Devices that analyze the physiological factors are still being developed using the open source and widely available hardware/software, what remains to be a challenge to this day is the experience of the end user who uses such systems, they should be easy to use and quite user friendly as placing sensors by the end user might be a hassle. The work in progress right now is trying to target the limitation in the available framework which is currently being used by products [5].
There are many obstructions to be overcome before Telemedicine can be generally deployed. Presently, in the United States, specialists are required to acquire licenses in each state in which they intend to prescribe drugs and see patients [6]. Moreover, lawful priority for remote risk has not yet been built up. Repayment strategies are additionally not all around well characterized. Tele-radiology exams are the main Telemedicine sessions that consistently get repayment [6]. Another real impediment to Telemedicine is the shortage of high data transfer capacity in rural zones, which remains a noteworthy issue even as Telecommunications organizations across the nation are moved up to help the national information infrastructure (NII). Moreover, the underlying expenses of hardware and the repeating costs of Telecommunications administrations are significant. Notwithstanding, late acknowledgment and sending of picture archiving and communications systems (PACS) in healing centers and the Digital Imaging and Communications in Medicine (DICOM) standard can give a foundation to encourage the usage of Telemedicine frameworks [6].
The DICOM standard can trace its roots to 1983, when the American College of Radiology and the National Electrical Manufacturers Association began to create a standard method for the digital transmission of medical images. The resulting ACR-NEMA standard was first published in 1985 and later revised as version 2.0 in 1988. Version 3.0, published in 1993, was associated with a name change to Digital Imaging and Communications in Medicine.
DICOM specifies a standard network protocol for communications and defines information objects not only for images but also for patients, studies, reports, and other forms of related data. The goals of DICOM are to achieve compatibility and to improve workflow efficiency between imaging systems and other information systems in healthcare environments worldwide.
Every major diagnostic medical imaging vendor in the world has incorporated the standard into its product design, and most actively participate in the enhancement of the standard. Most of the professional societies throughout the world have supported and are participating in the enhancement of the standard as well.

Network Model and Interfaces
This section discusses the network model and its interfaces. The system is considered as a platform that connects many patients with many doctors via servers as shown in Figure 1. The system consists of two GUIs; one for the doctor and the other for the patient. The doctor's GUI enables them to monitor the status of the patients and advise them through a notification with the right medicine that they can get. Moreover, there is a classic conversation application as the patient might have some questions to the doctor.
The implementation of the GUIs is conducted using MATLAB as it can do complex calculations of matrices and big data. But, in order to send more complex data using a created database, a high level language like C# was required to deal with the SQL server using Visual Studio to make the server connection between the doctor and the patient able to handle other types of data such as the patient picture, chat and previously mentioned medical data. As mentioned earlier, the system consists of two databases; one for the doctors and the other for the patients as it is many-to-many system where many patients can be examined through the system and where many doctors are available. Moreover, each row in the system's databases table represents a session between a doctor and patient who will be automatically matched if the patient's session is available and can be handled by a doctor while both of them are either online or offline. Furthermore, the conversation box has flags that can be either active or seen, and one can leave a message to the other for an advice or an inquiry. The (seen) flag tells the doctor that a patient is available to begin a session, and the active flag notifies the doctor that the session is running. There are other columns in the table that can carry other data like (visitID) which is unique to prevent two doctors from joining the same session. Another column is (patient picture) which is simply a binary array which stores current patient picture in the database. To save space, only one picture is to be sent at the beginning of each conversation.
The last columns are responsible for the chat between the doctor and patient as well as the status of each one of them being online or offline. It is simply two flags and two strings one for each of them.
This work is to let the database engine handle which doctor will contact which patient. This is done with the help of C# code that is discussed later. For simplicity, the program was created as a portal for both of doctors and patients with some differences in the program based on the user chosen role.
The patient's portal takes the input data from a webcam, keyboard, and the medical kit which will measure the vitals of the patient. The program then sends all this data over the cloud to the database server which will save it and make it ready for the doctors to access. The doctor's portal will take the input from the keyboard, get all the collected data from the database server, and sends the doctor's chat messages and status to the patient through the database as well. A simple story board has been created with some figures to make it easy to use the program and make it as useful as possible for the users. Figure 2 shows the Home Page of the portal where the user identifies themselves as a doctor or patient. Figure 3 represents a chat example with a message from both sides.

Implementation of The Network Model
This section shows the implementation of the network model that can enable the doctor to connect with a patient via different wireless communications technologies and enable the doctor to monitor the patient and send consultancy messages in real time. Figure 4 shows the flow chart of the network model that facilitates a smooth operation of the network.

Fig. 4. Flow Chart of the Network Model
To have a full overview on the communications channels that can be used in this network, the network model is implemented over three wireless communications technologies; Wi-Fi, GSM, and Bluetooth with four different medical vital signs that can be measured using heart rate, humidity, temperature, blood pressure, and alcohol sensors. Three Arduino ATmega_32 boards are used to test them as each has one RX and TX (one UART) and each controller is equipped with a solar cell to make the system available even if the power is disabled.
The Wi-Fi module is used to transmit the data collected from humidity sensor. While, the Bluetooth, and GSM modules are used to connect the heart rate sensor. Moreover, temperature sensor and alcohol sensor are connected using GSM. A push button is integrated with the system to allow the patient to call for an ambulance if needed. The system used Hc05 Bluetooth module [7], ESP8266 (ESP-01) Wi-Fi module [8] and SIM 908 GSM module [9]. While the sensors used are; Alcohol sensor [10], LM35 temperature sensor [11], heart rate sensor [12] and Humidity sensor [13]. Figure 5 shows the hardware implementation of the system. The idea behind using multiple communication technologies, is to test their performance in order to determine the one most suitable to the requirements of the proposed system.  Table 1 shows a comparative study between the three technologies. The three technologies were compared by the transmission delay, throughput, cost, range, and infrastructure. GSM can support very large distances (1m -40km, based on base station type). However, it requires cellular infrastructure and it only offers low data rates (in terms of kbps). Moreover, the cost of transmission is high and it has moderate transmission delay compared to the other technologies.

Discussion
Wi-Fi can support moderate distances (1-40m for indoor networks and up to 90m for outdoor networks) with routing and internet infrastructure. High data rates can be reached (~54 Mbps) with moderate cost of the router and internet registration fees, but it suffers from high transmission delay.
Bluetooth can only support limited distance (1-10m). However, it doesn't require any infrastructure. But as a plus, moderate data rates (~24 Mbps) can be achieved with low transmission delay and cost.
From this analysis, Bluetooth technology is recommended in the network where all components of the system are in the same room and there when there is no need to access the internet. On the other hand, Wi-Fi is suggested in a system that requires access to the internet as it supports high data rates with limited infrastructure and cost.

Conclusion
This paper proposed a platform that can be adopted in IoMT where patients can get in contact with one of the doctors remotely. Additionally, sensors can be attached with the sessions opened to allow the patient's vitals to be uploaded to the system. Doctors will be able to review the measured data online and advise the patient with the appropriate course of treatment remotely. This system was tested using five sensors: heart rate, humidity, temperature, blood pressure, and alcohol sensors using 3 ATmega_32 (Arduino board). Additionally, three communications technologies were used to connect the sensors with the server which are; Bluetooth, GSM and Wi-Fi. A comparative study between the three technologies used to connect medical sensors to the servers is discussed. best suited technology is suggested with regard of the nature of the application itself. Bluetooth and Wi-Fi technologies are recommended for similar networks that may /may not require to access the internet. Similar networks doesn't have to cover long distances and they can support high data rates for the video streaming. The proposed network model can be extended by adding a payment mechanism from the patients to the doctors within secure framework. Moreover, integrating GPS with such a system would make it more accurate for the instant emergency case which would be easier for EMTs to locate its place in the case of emergency.
King Fahd University of Petroleum and Minerals, Dhahran, Saudi Arabia, and a PhD '15 in Telecommunications engineering from the electrical and computer engineering department of the University of Porto, Portugal. His research interests are in the fields of IoT, WSN, and wireless communications.