Cloud based Tele-Monitoring System for Patient Care

Cloud based Tele-Monitoring System for Patient Care

Dr. P. S. Ramkumar1, Balasubramanya Vasista2, Chandan Prakasp, Sandeep Patil H G4, Prasanna Datha5,

1,2,3,4,5Applied Cognition Systems Pvt Ltd , Bengaluru, Karnataka

Abstract: This paper illustrates the design and implement of a cloud based Multi-Parameter-Monitoring system for remote health management of patients. The system supports data acquisition and monitoring of vital signs and symptoms as well remind and track diet, medication and exercise schedule as per prescription. Such a system enables continuous remote care extended from hospitals to homes of patients, saving travel, cost and inconvenience to the patient. The design incorporates embedded interface which can be programmed to interact with heterogeneous biomedical equipment and remain agnostic to manufacturers, while providing a common integrated framework for tele-monitoring[7].

1. INTRODUCTION

   Currently hospitals lack facilities to remotely monitor the recovery of their patients after being discharged, unless patient visits the hospital again. Quite often, this leads to relapse of the patients ailment and forces re-hospitalization. This gap can be addressed with technology support wherein hospitals can be enabled to monitor the health parameters of discharged patients in their homes. Lack of relevant information at right time and place has a profound impact on health care especially in the context of developing countries where equitable access to care is challenged by affordability, illiteracy, travel and logistic inconvenience, and uncertainty due to shortage of facilities/doctors/nurses. Such demography needs a simple-to- use tele-monitoring platform that provides a means to monitor health comprehensively while keeping the patient-end operation very simple and compatible to available internet infrastructure. Such a system should also be agnostic to which company the bio-medical equipment comes from, to accommodate a large scale use.

2. LITERATURE REVIEW

   Many researches are done in order to design various types of multi parameter monitoring system. A number of portable devices for monitoring vital parameters such as heart rate, respiration rate, temperature, blood pressure, oxygen, Co2, etc., have been proposed for remote physiological monitoring [1-6]. Shih et al [1] have proposed a telemedicine system based on an 8-bit processor for monitoring the ECG signal of elderly patients. One interesting feature is that radio frequency technology was incorporated to avoid the problem of mistaken identity. Ken et al. [2] presented a description and system architecture for a tele-cardiology monitoring system based on the Wi-Fi network. In [3] the authors developed a single lead

   system for on line acquisition of the ECG signal where processing is accomplished using a table-top model with PC- based Graphical User Interface. The authors in [4] report a Holter based vital sign monitor wherein snapshots of data are captured and sent Multimedia Messaging Service (MMS). In

   [5] the authors present a prototype for monitoring the users ECG and physical activity using accelerometer data, wherein a handheld device collects data from the sensor using Bluetooth and then forward to a backend server using the cellular network. In [6] a multi parameter monitor measures blood pressure, oxygen saturation in blood (SpO2), and the ECG signal and is capable of sending threshold based alerts using a GSM transceiver through mobile networks. Quite independently, advances in mobile phone industry have enabled simple applications such activity schedulers and reminders (which could include things like medication, feeding, exercise, etc.). These applications expect the patient/kin to program the schedules on apriority.

   Most of these systems are packaged as individual devices, resulting in product silos, each with their own operating protocols, look and feel, and many times locked with different passwords for each individual. Their data outputs are not compatible and they are not integrated into a common framework for remote controlling, tracking and alerting the care provider in events of non-compliance to schedule. Inside the ICU of a hospital, Holter systems bring such data of multiple patients to an ICU nurses table and charts are maintained indicating patients diet, medication and symptoms. The nurse is closely monitoring the patient status and will escalate the matter to a doctor if necessary and the doctor may ask the nurse for specific details and give opinion. But when a patient is monitored at home there may be no nurse and patients or kin may call in the doctor many times for non- critical issues. There is also lack of comprehensive real-time and historic information as needed by a doctor to take decision about further treatment remotely. For example, the doctor may need to know symptoms (e.g. vomiting /headache/ sweating/giddiness/etc.) faced by the patient, check if the patient missed prescribed diet and medication, and if patient has any history of allergy to specific drugs before administering a change in treatment. They may want to talk to the patient or care taker immediately before take any action. Driven by such a need, a framework that enables mobile acquisition, processing, monitoring, alerting, presentation of historical and real-time data, and conversation between the doctor and a remotely located patient and/or caretaker is presented in this paper.

3. SYSTEM OVERVIEW

   The typical workflow involved in a monitoring system as viewed from a doctors end, is outlined in block diagram of Fig

   1. The system must be able to primarily alert the doctor electronically, when the patient being monitored has an adverse condition. When alerts are received, to infer the patients condition the doctor can inspect the patients data. To assess the situation the doctor may also converse with the patient or their care taker by phone/video call and send offline suggestions in non-critical circumstances. Apart from conversation with the patient, the doctor may make formal recommendations to change diet/medication/treatment or prescribe new tests to be conducted. In some circumstances, the doctor may also advice that the patient should be brought to the hospital. Such a monitoring process may be periodic for extended periods in case of chronic conditions or may become bursts of intensive monitoring in case of episodic critical conditions.

   interfaces (USB/Bluetooth/WIFI/ RS232C/SPI/Ethernet/etc.,). The handshake protocol to control and exchange data with the device may be different(dicom/proprietory). The format of data emitted from the device may be different(little- endian,bigendian,lead order,etc). The parameters emitted may be different (HR/RR/lead-drop/raw-data/etc). The information may be represented differently (8/16/24/32 bit int/float/text/etc). Similarly when the data is to be sent to a remote site where the doctor is, the available backhaul connectivity may be different(land-line/wirelesss2G/3G/4G). It is required make sure that the control and data available to the doctor is same irrespective of this heterogenity and stay nuetral to any device manufacturer. The data acquisition system (DAS) presented in this work has building blocks as indicated in figure(2) to address these gaps.

   Doctor-end Laptop/Tab/Smart Phone

   Doctor-end Laptop/Tab/Smart Phone

   Get Alerts

   Doctor

   Doctor

   Assess situation

   Advice Action

   data acquisition

   Patient History

   Patient History

   Automatic Monitoring

   Chat/Audio/Video Interaction with patient / Care taker

   Chat/Audio/ideo Interaction with patient / Care taker

   Real-time measurement and symptoms

   Change Treatment/ Diet/ Medication / Exercise

   Change Treatment/ Diet/ Medication / Exercise

   Prescribe tests/ modify routine measurements

   Back-end Web Application and Storage

   Back-end Web Application and Storage

   Backhaul (DSL/2G/3G/4G) Network abstractor

   Backhaul (DSL/2G/3G/4G) Network abstractor

   Backhaul Abstractor with store-forward

   Backhaul Abstractor with store-forward

   Device Protocol Abstractor

   Device Protocol Abstractor

   Data Format Abstractor

   Data Format Abstractor

   H/W Port Abstractor

   H/W Port Abstractor

   Patient End Devices

   Patient End Devices

   Bring patient to hospital

   Bring patient to hospital

   Figure 2 Building blocks of Data acquisition System

   Figure 1 Tele-Monitoring Activities

   Each block has associated technological enablement to function effectively as needed for such a system, using a smart phone/laptop/tab on the doctors side and an ordinary mobile phone on patient side to communicate with bio-medical devices, video conference and upload textual data during the course of the monitoring service. The detailed functionality of each block is given below.

   1. Patient Monitoring

      Data Acquisition: One of the challenges in such a system is the need to be agnostic to bio-medical devices from different manufacturers. For example, consider the need to monitor ECG of a patient. Depending on the manufacturer, athough the data needed is ECG, the device may follow different hardware

      The DAS provides three levels of abstraction to enable common operational protocol for devices from different manufacturers. The first is a port abstraction layer for hardware interface to the device so that any type of standard hardware interface can be used to suit the device. This abstraction makes it possible to bridge devices which serial port, bluetooth, wifi and zigbee communication ports onto the acquisition system. Secondly, a protocol abstractor layer communicates with the backend through a common set of messages while it converts the messages into the manufacturer and model specific protocols on the device side. For example, the protocol running on a mobile phone can discover a device and its properties and operate the device through a common set of commands to start and stop data acquisition, check device status, select control options on the device, etc., based on the properties. This enables having a common communication protocol at the backend to handle devices from different manufacturers. The third layer is a format abstraction layer to nuetralize the

      hetergenity of formats, ordering and accuracy of data emitted from the device into a common form so that the backend system can rely on a common data handlers for storing and processing the data, irrespective of the manufacturer specific variations.

      Further a backhaul adapter has been built to enable communication between the device and backend web- applications through a broad band landline connection or a mobile phone based 2G/3G/4G data connection. The adapter has been equipped with necessary security and communication protocols for SOAP based HTTPS transactions with the webservices that are exposed by the back end application. The adapter has also built-in store and forward architecture to provide resilliance to telecom network failures and fail-safe mechanism in event of session drop-outs. Separate web- methods are enabled to handle control (which has less traffic) and data paths (which have heavier traffic) to enable scalable deployments over large number of service points. This way the architecture accommodates new protocols, format conversions and hardware interfaces, for enabling immunity from technology obselecence without adding to learning curve and operational complexity to the end user.

      Data Processing: The data thus acquired is stored and sent for further processing on the back end servers. The monitoring system is a software implementation, configurable as to which parameters are to be monitored for a given patient along with the corresponding boundary conditions which are to be tracked for each parameter. The monitor can be also configured to consider boundary excisions from a combination of parameters as per advice of the doctor handling the observation. As long as the data used for monitoring has been normalized by format abstraction during data acquisition, it can use data from devices of different manufacturers. For example, one could set an alert condition if the patient did not inform having taken medication and/or diet when remined by the system last time and the bp and heart rate was found abnormally high or low. Such alerts could be set by a nurse or technician who is delegated monitoring responsibility of the given patient. The system can send alerts to the monitoring nurse, by SMS to their mobile phone as well as pop-up alarms on their monitoring console. Once an alert is issued, the system remains in alerted state for that patient until reset by the monitoring nurse.

   2. Situation Assessment:

      Data Inspection: Once an alert is received, the monitoring nurse may follow a pre defined protocol based on the situation. The first step would be to inspect the monitoring data associated with the patient and decide if the situation is to be escalated to the respective doctor or if the patient is to be contacted. The system is designed to allow nurse to contact the patient and their kin on mobile phone without having to remember the patients name or numbers. At the lowest level of criticality, the nurse may just have to call the patient and guide them through some pre-defined steps to reduce the risk. In case the patient cannot communicte verbally, the nurse may also be able to share textual chat with the patient.

      Interaction with Patient/Kin: If a higher level of criticality is sensed from the data or during the discussion, the nurse may

      decide to escalate the matter to respective doctor. In such situations the system provides for alerting the doctor and sharing patient records and monitored information immediately and pull the doctor and the patient together into a conference call. The doctor may have a look at the patient, talk to them or their kin inspect the historical records of the patient along with the monitoring information to make a decision. All types of records such as radiological images, ecg and other waveform signals, textual inputs for tracking diet/ exercise

      /medication /symptoms and measurements such as Blood pressure, Oxygen Saturation, temperature, Blood Glucose, etc., are displayed can be accessed and inspected by the doctor during the session.

      Medical Advice: Depending on the situation the doctor may decide a specific treatment or advice the patient a particular activity or even recommend for admission to a hospital. This advice is captured by the electronic prescription and verbal record along with the data records that were used for such decision making to allow for supporting medico-legal requirements. The prescription is immediately available to the nurse and the patient/kin to follow accordingly. If needed, the monitoring nurse can also engage with the patient/kin for further support as needed in training or organizing logistics of ambulance, treatment, etc as prescribed, utilizing the same system. All records generated by all parties are continously indexed and archived for future use. Long term trends of recovery of the patient can also be generated from this data as needed. The system also enables measurement of efficiency indicators in terms of how much time it took from alert generation to response, how many times it was a false alarm, etc., to help in continous improvement of the services given.

4. TESTS AND RESULTS

   The system architecture was implemented using Android 4.4, and the same works on versions 4.4 and above, Microsoft Server 2012 R2, MS-SQL 2014 based web database worked ith any cloud servers like BigRock and GoDaddy and biomedical devices used were Applied Cognition Systems Multi-Parameter Monitoring Front End(MPM), APCOG IOT Controller, Bluetooth HC-05.

   The schedule of medication, diet, treatment and measurement according to prescription is captured on a registered mobile phone of the patient and the attending nurse or kin as shown in figure 3. Accordingly, reminder alerts are generated on the mobile phone with details of the prescribed medication/diet/treatment / measurement along with instructions prescribed. Such reminder can be acknowledged by the patient when completed, including uploading of measurements and symptoms like cough, vomiting, bleeding, etc. if any as shown in fig4. For trials measurements of Blood Pressure, SPo2, Temperature and Heart Rate and corresponding measurements were uploaded as textual inputs shown in figure (5) as well as directly captured from the medical device by a direct interface as shown in figure (6). To record the waveforms like ECG, SPO2 etc. directly from the biomedical device, we have the client application has been instrumented to follow a common protocol irrespective of the device, in order to

   1. discover the device

   2. pair the device with the phone

   3. list the parameters that the device can acquire

   4. select the parameters needed

   5. select particular leads in each parameter

   6. start and stop acquisition

   Such measurement data and activity log is stored by backend web services into patient health records. The acquired data can be stored and checked episodically, or streamed to an observation desk in real time. The observation desk displays all relevant parameters of the patient to the monitoring nurseas shown in figure 8). If there is any is continuously Further the parameters could be checked against thresholds and combinatorial login involving multiple parameters gives rise to alerts in deserving conditions of the patient, in terms of the parameters being compared to threshold. When alerted, the attending staff can place a video call using this application to talk to the patient/kin in case of emergency or daily follow up

   Figure 3 Figure 4

   Figure 6 Figure 5

   Figure 7 Real-time multi parameter stream from multiple patients onto monitoring nurse console

   Figure 8

   Data from multiple patients were co-hosted on a common monitoring terminal and alerts were highlighted on respective patient tabs to a monitoring nurse who was remotely located. The tabs were provided with facility to drill down specific reports of monitored parametric details as shown in figure 8 where conjugated data of medication intake over a selected

   period of time is displayed showing compliance to prescription for dosage, schedule and before/after food recommendation. Screenshot of the monitoring stations, displaying multiple patients data. Out of bound parameters are highlighted in red These trends help doctors analyse the drug response on the body when viewed with variations in the vitals during medication.

   Figure 9

   The system was configured for automatic detection, alerting and escalation with video conferencing features to the monitoring nurse to contact the patient and doctor as needed based on the monitoring parameters and set experimental thresholds for the parametric values. Alerts were received on monitoring nurses mobile and if needed the nurse or doctor entered into video conference with patient using interface shown in fig(9). Multiple parties could be simultaneously in the call such as the patient, their care taking kin/nurse, doctor and additional specialists as needed. The entire functionality mentioned above was tested successfully with volunteers in mock roles as patients, doctors and nurses using their laptops and mobile phones to transact with the monitoring application hosted on a cloud based server.

5. CONCLUSION.

The system clearly demonstrated technical feasibility of remote monitoring and demonstrated avoidance of unnecessary travel and inconvenience enabling timely attention and information at the hands of doctors, nurses and kin even at odd times and when they were at distant places. The system can showed capability to form a central monitoring network connecting multiple patient homes to care providing clinics, hospitals, nursing agencies and labs which assist in periodic measurements, as shown in figure(10). A larger scale deployment would also entail development of multi lingual and iconic user interfaces and high concurrency infrastructure along with field-configurable monitoring parameters based on individual patient situations.

REFERENCES

1. H. C. B. L. S. L. D.H. Shih, An embedded mobile ECG reasoning system for elderly patients, IEEE Trans. Inf. Technol. Biomed, 2010., vol. 14, pp. 854-865.

2. C. Ken and L. Xiaoying, Development of WI-FI Based Telecardiology Monitoring System, in 2nd International Workshop on Intelligent Systems and Applications (ISA), 2010.

3. J. B. M. M. R. Gupta, Development of an embedded system and MATLAB-based GUI for online acquisition and analysis of ECG signal, Measurement, 2010, vol. 43, pp. 1119-1126.

4. M.-F. Y. K.-C. C. R.-G. L. C. Wen, Real-time ECG telemonitoring system design with mobile phone platform, Measurement, 2008, vol. 41, pp. 463-470.

5. J. Healey and B. Logan, Wearable Wellness Monitoring Using ECG and Accelerometer Data, in In Proceedings of the Ninth IEEE International Symposium on Wearable Computers (ISWC '05), Washington, DC, USA, 2005.

6. U. Anliker, J. A. Ward, P. Lukowicz and Troster, G.; Dolveck, F.; Baer, M.; Keita, F, AMON: a wearable multiparameter medical monitoring and alert system, Information Technology in Biomedicine, IEEE Transactions on, 2004 , vol. 8, no. 4, pp. 415-427.

7. Dr. P. S. Ramkumar Scaling e-Health Services in step with ICT Transformation https://www.itu.int/ITU- D/cyb/app/docs/Scaling%20e-Health-E.pdf

Clinics / hospitals

Nursing agencies

Tele- monitoring network

Homes

Labs

Figure 10 Proposed scalable Tele-monitoring network