Abstract
It is a clinical fact that better patient flow management in and between hospitals improves quality of care, resource utilization, and cost efficiency. As the number of patients in hospitals constantly grows, the need for hospital transfers is directly affected. Interhospital transfers can be required for several reasons but they are most commonly made when the diagnostic and therapeutic facilities required for a patient are not available locally. Transferring a critical patient between hospitals is commonly associated with risk of death and complications. This raises the question: How can we improve healthcare team collaboration in hospital transfers through the use of emerging information technology and communication services? This paper presents a cloud-based mobile system for supporting team collaboration and decision-making in the transportation of patients in critical condition. The Rapid Emergency Medicine Score (REMS) scale was used as an outcome variable, being a useful scale to assess the risk profile of critical patients requiring transfers between hospitals. This helps medical staff to adopt proper risk-prevention measures when handling a transfer and to react on time if any complications arise in transit.
1. Introduction
Interhospital transfers (IHTs) of patients, also known as interfacility or secondary transfers, are an integral part of healthcare services delivery. There are a variety of reasons why patients may require IHTs [1]. Patients may require transfers due to the lack of critical care facilities or beds in the referring hospital. Others may be in need of more specialized treatment and equipment available only in more sophisticated facilities. A commonly used classification for transfers is as follows: (a) primary transfers, moving the patient from the prehospital setting to the receiving hospital; (b) secondary transfers, hospital to hospital transfers, including to tertiary centers; (c) tertiary transfers, moving from secondary or tertiary hospitals to a national center of expertise; and (d) quaternary transfers, international transfers.
This situation leads to healthcare and transportation services often needing assistance with logistics and decision-making. Specifically, IHTs are needed when the diagnostic and therapeutic facilities required for a patient are not available locally [2]. Unfortunately, it is common for complications to arise during transportation. The decision of transporting a patient must be done after balancing the potential benefits of transportation and the risks involved. Although meticulous pretransfer checks can be made to assess the risks, patients’ vital signs may be subject to major variations while traveling [3].
Chile’s current emergency medical transport system is managed by SAMU (Emergency Medical Care Services). It provides a central hub for first response vehicles and ambulances with or without a physician on board. However, most ambulances are not properly equipped to be able to remotely monitor the patient’s vital signs while being transported. SAMU has had many problems with equipment on board their ambulances. The devices they use are very large and are not suited for emergency transports: some are very fragile while very few are capable of transmitting data to a server. Often sudden accelerations, stops, and the constant vibration inherent of an IHT can significantly alter the measurements of the sensors and even break the equipment, resulting in huge monetary losses. SAMU also manages communications between vehicles and hospitals through radio channels, which puts the responsibility of analyzing the patient’s condition entirely on the personnel on board and creates coordination difficulties for simultaneous transfers. Despite an increased interest in embedded devices, mobile applications, and cloud platforms, there is still a gap between current vital sensor design used by SAMU and the actual requirements of the physicians and doctors monitoring the patient being transported.
This project tries to fill that gap by providing a low-power embedded solution capable of capturing some of the patient’s vital signs, such as heart rate and oxygen saturation, and sending them to a smartphone using wireless connectivity. Patients’ vital signs are monitored by embedded devices fitted with vital sensors. Outfitting patients with such devices enables the capturing and transmission of real-time vital sign data. This in turn allows for the construction of remote monitoring platforms and intelligent mobile applications in order to improve the healthcare team collaboration in IHTs. By centralizing this information in the cloud through the smartphones’ cellular radio, offsite physicians can support paramedics in their decision-making process while simultaneously monitoring the patient’s vital functions. This project aims to establish a risk assessment platform to be used to determine whether or not to transport a patient through SAMU, trigger early responses to in-transit complications, and overcome many of the current monitoring system’s shortcomings.
Section 2 describes the current state of the art in mHealth technologies with a focus on mobile telemedicine. Section 3 describes emerging trends in information technology for healthcare services. Section 4 describes the Rapid Emergency Medicine Score (REMS) research carried out in Chile. Section 5 presents the proposed system and Section 6 presents discussion, conclusions, and future work.
2. Related Work
Mobile telemedicine is the science of providing healthcare services to distant patients through the use of information and communication technologies. It has been the subject of study for several decades as the early provision of prehospital attention to critical patients can mean the difference between life and death, yet mobile telemedicine solutions have always been limited to inherent mobility-related constraints such as limited throughput and connection unreliability. One of the first documented mobile telemedicine initiatives is the AMBULANCE telemedicine system [4] proposed in the early 1990s. It featured a biosignal monitor hooked up to a notebook computer with a GSM modem. It allowed the transmission of 320 240 JEPG images and real-time biosignals of the patient (ECG, heart rate, blood pressure, and oxygen saturation) to a medical team monitoring the situation at long distances. The architecture followed a client-server model where the client would be responsible for establishing communications, sending the data, and requesting a patient’s medical record if needed. The system used the TCP/IP protocol over GSM and was capped at a maximum speed of 9.6 kbit/s due to the limitations of 2G technologies at the time.
Later, advancements in mobile networks saw many new mobile telemedicine initiatives taking advantage of them to develop new applications. The WAP telemedicine system [5] introduced mHealth applications to devices available to consumers: in this particular case, a WAP-enabled phone. It allowed for the storage and relay of ECG signals, patient history, hospital messages, and the physician’s advice. In 2004, a system that would allow for the transmission of still images, videos, and vehicle control and management was proposed [6]. This saw the addition of GPS and wireless camera equipment to the ambulances to provide richer information. Reliability was still an issue in the less developed rural areas where mobile network availability was less abundant. To tackle this challenge, the authors in [7] proposed a system that would cycle through multiple wireless communication standards in order to send the information through the most reliable channel.
Moving on to 3G networks, the platform proposed in [8] introduced a cost-effective portable system implemented through a laptop or tablet that would collect and relay ECG signals, medical images, and real-time video. These would then be sent through 3G to a hospital unit implemented in a desktop computer. Such features were only made possible by the increased data transmission rates of the new networks. A similar device is presented in [9], where an ultramobile PC with a camera and a microphone/earphone was hooked up to a WIBRO modem for wireless connectivity. This solution would exploit the increased QoS, area coverage, and bit rate transmission of WiMax to successfully enable teleconferencing between paramedics and the medical staff in the hospital. However, testing in practical conditions showed that the device only met basic performance parameters, mostly due to connection reliability issues.
Mobile telemedicine systems in ambulances exploiting 4G LTE-advanced are less common in literature due to their relative novelty, but they are still fairly abundant in the areas of remote patient monitoring and self-care. These technologies are fairly predominant in the context of body sensor networks. BSNs are a subset of wireless sensor networks in which sensors are explicitly used to monitor an individual. However, effective implementation of BSNs is very challenging because of the large amount of data streams being generated concurrently. They need to be collected, processed, and analyzed in order to generate information of use to the patient or medical staff. Other operational challenges include privacy, security, and the seamless integration of heterogeneous devices. Efforts into streamlining this process have led to the creation of BSN frameworks such as BodyCloud, a cloud computing system architecture for the management and monitoring of body sensor data streams [10], and C-SPINE, a framework for collaborative BSNs enabling sensor discovery, activation, execution, intercommunication, and data fusion [11]. Bourouis et al. present an example of a specific BSN implementation in which they make use of a mobile device to collect kinematic and physiological parameters of elderly patients via Bluetooth. This data is analyzed and sent to a server upon any relevant perceived change [12]. A similar architecture is presented in [13], although the collected information is further enriched by the patients’ own status logging and social network messaging information. The data is later referred to a server via a SOAP API.
A thorough survey of mobile telemedicine solutions for moving vehicle scenarios is available at [14]. Batistatos et al. [15] also analyze the same kind of technologies but their research is more focused in their requirements, characteristics, benefits, and limitations. They conclude the biggest challenge of telemedicine in mobile scenarios is the continuously changing operational environment. Therefore, solutions should either support adaptive networking to adapt to whatever infrastructure is currently available or be fully functional in situations where network availability is poor or nonexistent.
Our system is designed to take advantage of the latest APIs and mobile devices available to consumers to create a low-cost solution for vital sign monitoring in the specific environments of patient pickup and IHT. We do not delve into resource intensive multimedia interactions as communication reliability has been shown in several of these studies to be a very important issue. Instead, we focus on the set of parameters that is most likely to affect patient survivability during emergency transfers. We make those available to the local paramedic team and use them to calculate a global score. This information is then shared to the medical staff at the hospital as long as a network connection is available; however, the primary function of the system is not impeded by lack of connectivity and paramedics may still yield some benefits from the solution in such scenarios.
While many remote patient monitoring initiatives exist, these are mostly meant for static contexts and do not consider the constraints introduced by mobility. Others limit themselves to simple monitoring of vital signs and do not perform any historical data analysis to proactively alert physicians of any irregularity, or they may be dependent on a high quality wireless network being available, often not the case in less developed areas. Our solution was specifically designed with these goals in mind.
Section 3 describes emerging trends in information technology in healthcare services that have been considered in our cloud-based mobile system proposal.
3. Mobile Cloud Computing and Healthcare Services
Cloud computing is a model for enabling on-demand network access to a configurable set of cloud resources with minimum amount of developer effort. These resources can be rapidly allocated or released depending on the current server demand either automatically (e.g., Amazon EC2) or manually. Cloud computing has been used in mobile healthcare services for several years now and it has been effectively demonstrated to ease development of health-related architectures [16]. Nevertheless, integrating these services with mobile platforms is far from trivial and that constitutes a different challenge altogether. Effective mobile telemedicine solutions are required to support pervasive and ubiquitous access to data and to properly process it with limited hardware resources and without excessive battery usage. Ideally they should also support at least partial offline functionality and automatic database syncing.
Infrastructures that allow mobile platforms to harness the resources of the cloud and support the aforementioned features belong in the category of mobile cloud computing (MCC). A MCC architecture consists of a mobile and cloud component connected by the Internet through a mobile network. Cloud services are deployed on a cluster of servers usually managed by a cloud service provider (e.g., Google Cloud Platform, Microsoft Azure, and Amazon Web Services). Cloud services can then be classified based on the amount of customizability and control of the underlying system available to the developer versus deployment speed and ease of maintenance (see Figure 1). In this paradigm, we recognize three major categories: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) [17].
IaaS is highly customizable because developers are responsible for everything from setting up the operating system to deploying the application and configuring its runtime environment. General PaaS solutions like Web and Worker do a little more of the heavy lifting for developers because the service comes with an OS and certain middleware applications already configured. A subset of PaaS solutions targeted towards particular applications, such as Web, media, or mobile, could supply even more of the glue code the application needs. Finally, SaaS allows for little to no customization and supports only a specific software distribution. As such, SaaS solutions are tailored towards a very particular set of requirements.
In order to ease the integration of cloud services and mobile clients, there has been a recent surge of Mobile Back-End as a Service (MBaaS) providers that allow developers to establish complex mobile cloud interactions with very little configuration. These solutions provide programmers with two major features: on the client side, we have custom libraries for mobile clients made specifically for each relevant mobile operating system; on the server side, we have control panels that make extensive configuration possible in a matter of minutes. MBaaS not only enables the connectivity and scalability that come with all cloud-based services but also supplies solutions for common mobile development challenges like user authentication, push notifications, data storage, social media integration, geospatial queries, offline sync, analytics, and more. This provides a consistent way to manage mobile back-end requirements as services and removes the need for having to develop custom ad hoc solutions that more often than not suffer from serious performance and security issues.
As can be seen in [18], the usage of MBaaS is not foreign to healthcare applications, where it is used to greatly facilitate data routing, security, authentication, authorization, offline functionality, and service orchestration.
In the previous paragraphs we explained how mobile and cloud computing represents a drastically different approach to IT solution delivery and how this technology could be one of the foundations of the next generation of computing. The next section describes the importance of REMS in IHTs and the relevance of IT solutions for improving healthcare team collaboration in IHTs.
4. Understanding the Importance of REMS as a Risk Assessment Tool for Interhospital Transfers of Critical Patients
The Rapid Emergency Medicine Score (REMS) is an in-hospital mortality predictor for critically ill emergency department patients. It was first mentioned in literature by Olsson and Lind in 2003 and it has been proven to be superior to similar mortality predictors such as RAPS [19] and MEWS [20]. The REMS varies between 0 and 26 where a higher score signifies a greater mortality risk. It considers six variables: mean arterial pressure, heart rate, respiratory rate, peripheral oxygen saturation, Glasgow coma scale, and age. Each of them may contribute up to 4 points to the final score, with the exception of age, which may contribute up to 6 points. Table 1 summarizes in detail how to calculate the score. One of the main advantages of the REMS is its noninvasive nature and ease to determine. All of these variables can be either estimated by trained physicians or measured by common healthcare monitors. Despite its simplicity, it is a very powerful tool for assisting clinical decision-making.
Since its inception, there have been several initiatives to evaluate its applications to areas other than in-hospital mortality for ICU patients. In [21], a study conducted amongst traumatically injured patients found a similar correlation between REMS and in-hospital mortality (AUC of 0.91). For our case in particular, REMS has also been proven to perform relatively well when assessing mortality risk in interhospital transfers. In [20], researchers conducted a retrospective study amongst critically ill patients who underwent transfers to an ICU and found that REMS behaved reasonably well as a predictor of mortality (AUC of 0.72). They further emphasize that the REMS incorporated into electronic decision support tools can “assist clinicians in balancing resource, risk, and logistic options in complex patient transfer scenarios.”
In order to verify these results and assess the applicability of REMS to SAMU transfers, we conducted our own study to verify its effectiveness in evaluating the clinical state of patients undergoing secondary transfers between hospitals. We performed a retrospective analysis of all interhospital transfers made by SAMU in Santiago, Chile, between October 2014 and May 2015. In total, 3629 patients (61.9% male, 38.1% female) were included in the analysis. We considered the REMS at the beginning of the IHT as well as other relevant variables. This data is summarized in Table 2. By analyzing the relation between the initial REMS and patient mortality, our results showed an AUC of 0.72, thereby confirming the previously published results. Additional studies are available at [1, 22].
With this in mind, the REMS can be used as an early warning system to assess the seriousness of a patient’s condition. As such, patients are classified in one of three categories: low risk (REMS < 6), medium risk (6 ⩽ REMS ⩽ 13), and high risk (REMS > 13). Depending on the classification, additional precautions may be taken to secure a patient’s wellbeing during a transfer. In transfer, sudden REMS spikes are indicative of an increased mortality risk and may trigger early therapeutic actions from the paramedics with collaboration from the on-hospital medical staff that may save a patient’s life. These may include the use of vasoactive drugs, reevaluating the use of assisted oxygenation and ventilation, or rerouting the transfer to a nearer clinic. As a result, paramedics can take the appropriate measure at an early stage to avoid the patient’s physiopathological deterioration. Thus, we can prevent riskier and more aggressive interventions, lower the usage of clinical resources, and avoid prolonged hospital stays. Therefore, when initiating transfer of a patient with an intermediate or high REMS, constant evaluation must be maintained in order to identify potentially risky situations in time [3].
5. The Proposed Cloud-Based Mobile System
5.1. Applying Lean Startup as a Viable Methodology for Addressing Healthcare Research Projects with Multidisciplinary Teams
The lean startup movement made its first official attempt to break into the healthcare sector when Steve Blank launched The Lean LaunchPad for Life Sciences and Healthcare: the right way to redesign healthcare [23]. The goal was to teach researchers and clinicians how to move their technology from an academic lab or clinic into the commercial world. The life sciences class gathered together drug developers, software engineers, and medical device inventors and encouraged them to test their ideas before launching them as a business.
The lean startup principles are in many ways analogous to applying the scientific method to startups [24, 25]. That is, treat your assumptions as hypotheses, and then go out and test them starting with the most critical and cheapest tests first to turn your assumptions around the business model into data. Using lean startup principles allows multidisciplinary teams to present personal project or research ideas to be voted on by the broader team [24].
The core of the lean startup model is the Build-Measure-Learn feedback loop (Figure 2), employing a team of people with professional training that focuses on one element of this feedback loop [26]. Due to this, using lean startup principles allows this research to easily properly integrate multidisciplinary perspectives to propose a solution for healthcare research projects. The formation of an interdisciplinary team is particularly relevant as healthcare professionals have a greater insight of the needs of the healthcare sector, while computer scientists are more familiar with the key factors of the success of mobile services: identifying actual and potential open research issues, investigating how mobile services are influenced and how they behave (i.e., users’ behavior), and revealing what they really expect (i.e., needs and preferences).
This research used data exposed in Section 4, regarding the REMS scale as an entry point. During this initial learning phase, we identified the REMS as a useful predictor of the risk and severity of a patient’s condition during an IHT; however, it was not being actively used as a decision-making tool. Thus, we envisioned a platform that can compute, among other data, the REMS in real time and support decision-making for IHTs.
In the first cycle of this methodology, we focused on providing a set of tools to help in-hospital clinical staff and paramedics on board ambulances. Initial mockups were built as our first product and tested with real users. We used semistructured interviews to measure our first approach, identifying several key aspects regarding usability and architecture, thus informing us of which features added more value to the end users. Finally, in the learning phase, those comments and feedback were analyzed and consolidated, resulting in the improvement and validation of the proposed mockups and core features.
With the feedback gathered from the first cycle, our team moved on to focus on building and obtaining the initial Minimum Viable Product (MVP) that would incorporate the core features we determined. We divided our platform into 3 main components: a back-end, a mobile application, and a set of embedded devices. Each component tackles a core feature we identified: the back-end provides scalability and data centralization, the mobile application provides the monitoring interfaces, and the embedded devices were used for data extraction. We tested this first version of the platform with mock data to simulate real IHTs and used the same approach as the first cycle to gather feedback. The core features were well received, but the usability of our mobile application was identified as paramount to the platform’s success.
Finally, we fixed the problems identified in previous cycles and we built a stable release of the platform. The system was tested with a simulated transfer using our embedded sensors within a real ambulance. We gave access to healthcare professionals, undergraduate civil computing students, and nursing students to test the platform. Successful communication was established between the remote medical transfer team and the professionals on-board, and everyone was able to follow the REMS variation in real time.
5.2. The Architecture of the Cloud-Based Mobile System
Cloud-based mobile applications that provide constant monitoring features and guidelines for healthcare, such as our solution, can be classified under the field of collaborative systems. These software applications can be particularly challenging to implement due to mobility-related limitations in both the front-end and back-end [27]. Mobile front-end requirements are related to the intrinsic limitations of interacting with the device and are constant for most applications. On the other hand, requirements related to the application back-end are very varied and unique to monitoring and collaborative platforms. These include environmental (interoperability, heterogeneity, scalability, and availability), security (reliability and privacy), and performance (battery life, storage, and bandwidth) requirements.
In order to deal with these limitations, our solution augments the capabilities of mobile devices by incorporating mobile cloud computing principles. MCC architectures seek to leverage the capabilities of external resource-rich nodes to improve performance and battery life [28]. As such, our solution uses a smartphone simply as a hub and display for wirelessly transmitted data of a variety of sensors; it later relays them to a server in charge of all the computer-intensive processing whenever a network connection is available. This enables the server to process and analyze incoming data in real time in order to obtain statistics and contextual information without straining the battery of the mobile device [29].
Figure 3 shows the general architecture of the proposed system, separating functionality into three basic applications: (a) cloud-based back-end services for computational and data storage purposes, (b) mobile and Web applications that enhance collaboration and analysis between SAMU and medical teams, and (c) embedded and mobile applications that aid vital sign monitoring and improve communication within medical services.
Relying on this general architecture, the proposed platform works as follows. Before initiating a transfer, an in-office healthcare professional assigns the transfer to an ambulance by using the Web system. The paramedics of the designated ambulance are notified by the mobile system. Once the patient is ready and the sensors are connected to him, the transfer starts. During the transfer, the embedded sensors measure some vital signs and send the measurements to the mobile system. The mobile system calculates the REMS and displays the information graphically while sending the data to the cloud. Then, in-office healthcare professionals are able to observe all the information regarding the state of the patient in real time, which enhances the collaboration between different members of SAMU staff during the transfer. Figure 4 shows a sequence diagram of the process described.
5.3. Mobile Back-End as a Service
Back-end services enable convenient, on-demand network access to a shared pool of computing resources or services that can be rapidly distributed with minimal management effort. These cloud-based back-end services were used to gather data from multiple sensors and for providing access to this information to different users. Among the advantages of using the cloud to power mobile services are the following:(i)On-demand self-service: the resources can be used and accessed at any time.(ii)Broad network access: the resources can be accessed over a network from multiple kinds of devices.(iii)Scalability: users can quickly acquire more resources from the cloud by scaling out.(iv)Processing power: it permits reducing the computational time of complex tasks compared to devices with limited resources.(v)Security and privacy: authentication and authorization can be centralized.
The service platform is built with the Ruby on Rails (RoR) framework. It exposes a REST Web service through which it receives data and defines the protocols used by paramedics in case of emergency. Only authenticated users are allowed to interact with our Web services, therefore ensuring the patient’s medical data remains secure. For storage purposes, our cloud service uses SQL and NoSQL databases. The MongoDB NoSQL database was selected over a relational database due to its higher scalability and better performance when handling large loads of concurrent write operations [30]. This paradigm fits very well with the intrinsically write-intensive characteristic of sensor data collection applications.
The RoR services and database instances are hosted on Heroku’s cloud platform using one dyno, which is a lightweight Linux container that runs a single user-specified command. Namely, the components use the Platform as a Service solution, which allows us to manage the applications while avoiding the complexity of the infrastructure.
The back-end service needs to share and distribute data to several users and several devices and platforms. To achieve this, two technologies were adopted. The first is Google Cloud Messaging, which was used to send nonsensitive information from the cloud service to the mobile devices. The second is PubNub, which was used to provide real-time interaction with Web users as the data arrives into the cloud.
5.4. Front-End Web Applications
The primary goal of the Web application is to provide remote real-time tracking of patients being transferred. It is mainly targeted to medical regulators that can give remote assistance to paramedics in case of emergency. With this information readily available, they are able to promptly order a retransfer should the situation require it.
Medical data is provided graphically by charts that show the tendency of the clinical state of the patient (REMS and its parameters) for each active transfer. The technologies behind the application include RoR, AngularJS, and common Web technologies (HTML, CSS, and JavaScript). We used the Model-View-Controller design pattern for the back-end services and the Web application front-end.
The main layout of the Web application is shown in Figure 5. On the left side, there is a list of current transfers. When a transfer is selected, the tendency of the REMS and its parameters is displayed in charts on the right side. When the parameter being observed is in its normal range, the data is shown in green, but when it reaches dangerous values, it is displayed in red. Alerts generated by the mobile application are displayed at the top of this interface. They are removed when a paramedic attends to it or when the condition of the patient returns to a normal state.
Given that a deterioration in the condition of the patient could lead to serious situations, it is important to be able to provide correct directions to paramedics. One important decision is the change of the target hospital when the state of the patient requires it. In order to support this kind of decision, the Web application is capable of displaying a map that shows the location of the ambulance in real time (see Figure 6).
Finally, as transfers are completed, information disappears from the screen and is visible only to medical administrators. These health professionals have access to historical information on IHTs (see Figure 7).
5.5. Mobile Application
Monitoring systems provide a tool by which paramedics on board ambulances and medical regulators in SAMU offices can track the state of patients in transfer. It is achieved with the use of a mobile application and a Web application. Both of them interact with the back-end services to send and receive data in real time. The main components of the mobile application are listed below:(i)Communication: the mobile application manages the reception of data from sensors and the sending of processed data to the cloud.(ii)Transfer: it is in charge of performing updates of the user interface as new data is received.(iii)Storage: it manages access to different files that are stored locally.(iv)Location: it manages all the procedures related to determining the location of the ambulance.(v)Calculator: it performs the calculations needed for determining the patient’s REMS and breathing rate.(vi)Persistence: it is in charge of saving data when the mobile network is unavailable.
The mobile application was built natively on the Android Platform and requires a device running Android 4.1 or higher. It provides a simple graphical user interface that enables paramedics to monitor the patient’s vital signs over time through dynamic charts. These charts allow the paramedic to observe the tendency of the patient’s REMS and its parameters, while a panel displays the current values of those parameters. The application also includes a list of protocols and guidelines to be applied when specific situations occur during the transfer.
The mobile application receives data from the sensors by the use of a local Wi-Fi network. It then processes the data, calculates the REMS, and updates the corresponding graphs. At the same time, the information is sent to the cloud service by the use of the mobile network. If the mobile network is unavailable, the data is stored locally until a connection is reestablished. When this occurs, the data is sent on a last-come-first-serve basis.
Figure 8 shows the mobile application user interface. Its layout is divided as follows: on the left side there is a list displaying the current values of the REMS and its parameters. On the right side, there is a chart showing the tendency over time for the REMS. Selecting a specific parameter on the left in order to observe its own tendency in the chart is possible. At the top, there is a list of checkboxes that allows the paramedics to select special conditions that a patient could have. Finally, at the top right, one can observe alerts that are generated when potential risky situations are detected.
In addition, this application supports an optional Google Glass peripheral. The main advantage of Google Glass over other user interfaces such as smartphones is the ability to interact with it without the use of one’s hands. For instance, during an emergency, the paramedics’ attention must be centered on the patient and should have their hands free to attend to him. The paramedic would be able to take a picture of a medical case using the camera mounted on the Google Glass peripheral (see Figure 9). Google Glass sends the image to doctors in health facilities in order to receive indications of what procedure to follow. Thus, with Google Glass, paramedics can focus their full attention on the patient while the relevant information is delivered directly in front of their eyes.
(a)
(b)
5.6. Embedded Devices
The embedded application is designed to enhance the process of collecting data from wearable vital sign sensor devices. The sensor platform is composed of two components, the sensor device itself and a mobile application focused on vital sign monitoring and communication with the cloud platform.
Figure 10 shows the configuration of the different shields used by the platform. An Arduino Uno and an e-Health Sensor Shield v2.0 were used to support the retrieval of data from the corresponding sensors. In particular, an SpO2 sensor (see Figure 11(a)) was used for reading pulse and blood oxygen levels, while an airflow sensor (see Figure 11(b)) was used for calculating breathing rate. The SpO2 sensor is mounted on a finger of the patient. The airflow sensor is mounted on the head of the patient, with the sensor itself in the nose. These sensors were connected to the e-Health Shield through a wired connection. The e-Health Shield was mounted on the Arduino Uno, which was programmed to receive data and send it through Wi-Fi and the UDP protocol to the mobile device, using an xBee Shield and the RN-XV WiFly module.
(a)
(b)
The main advantage of the proposed setup versus the current equipment used by medical services is the low cost. Not only is every component of the arrangement available at very low prices, but each one of them is independent from the other. Therefore, eventual malfunctions that affect individual modules will not compromise the rest and the embedded device can continue to function while the defective module is replaced.
Two important constraints were present with regard to the sensors. The first was the fact that no blood pressure sensor that could send data wirelessly was available at the time the prototype was built. For this reason, this data had to be collected using the standard equipment available at the ambulance and entered manually into the mobile application. Nevertheless, it is possible to create automated blood pressure cuffs compatible with Arduino using very basic electronic components; we did not include one due to time concerns. The second constraint was that currently no respiratory rate sensor exists for Arduino. We managed to circumvent this limitation by adapting the readings of an airflow sensor. Our system takes airflow measurements every 50 milliseconds and infers whether it corresponds to the patient inhaling or exhaling. With enough measurements over time, it is easy to estimate breathing rate.
5.7. Results of Testing the Cloud-Based Mobile System
In order to test the system in a real environment, we performed a transfer of a simulated patient in an actual ambulance used for secondary transfers. Three paramedics were on board, while the rest of health professionals stayed at the office monitoring the transfer through the Web application (see Figure 12(a)). Continuous communication was established in order to compare the information in the mobile device to the information in the Web application. Figure 12(b) shows pictures of the sensors and the mobile device in use during a simulated transfer. The Arduino is in the gray box shown in the first image, while the mobile device is in the hands of a paramedic shown in the second picture. The second picture also shows the current equipment available in ambulances for monitoring the patient’s health state.
(a)
(b)
The ambulance’s path was approximately 6 km long, at points going behind hills in order to test the signal strength. The simulation called for an unconscious patient; therefore, Glasgow was assigned a score of 4 on the REMS. The simulated patient was also under respiratory assistance, giving a score of 4 for respiration rate. Thus, the initial REMS was 8, assuming that all the other parameters were evaluated with a score of 0.
The sensors were connected to the patient during the journey. Blood pressure readings were taken every five minutes and were updated manually in the mobile device. With the data, it was possible to observe how the REMS changed due to variations in heart rate as well as changes in blood pressure.
In terms of the usability and performance of the system, the sensor platform performed favorably compared to the sensors available on the ambulance. In fact, the readings were almost the same throughout the journey. One negative aspect was the fact that the heart rate sensor occasionally lost connection due to the vibrations that occur during ambulance transfers. The connection was interrupted for about 5 seconds and was therefore not critical. According to paramedics, these disconnections also occur with the sensor platform currently available on ambulances.
On the other hand, the mobile application gave constant feedback on the state of the patient in REMS terms via charts. The information was successfully sent to the cloud in real time around 98% of the time. The rest of the data was delivered with some delay due to the nature of mobile network signal. Nevertheless, since the downtime of the network was insignificant compared to its uptime, this was not considered an issue.
Another important aspect is the fact that the mobile application was capable of detecting disconnected sensors. When this occurred, the system assigned the worst possible score to REMS parameters, which was reflected as peaks in the REMS chart. The system also generated corresponding alerts, which prompted paramedics to check the devices. The Web application allowed the observation and analysis of information about the transfer in real time without issues. The tendency of the parameters was displayed in charts, as well as the generated alerts.
6. Discussion and Conclusions
This paper presents a novel low-cost cloud-based mobile system for assisting clinical decision-making in high-risk patients undergoing interhospital transfers. It has proven to be reliable enough to promote communication and collaboration between paramedics and in-hospital medical staff when mobile networks are available and to provide a valuable indicator of a patient’s status when they are not. The usage of Google Glass has also shown promising results, despite the hardware’s lack of maturity, and we expect to refine these solutions with future iterations of the Glass device. While battery life in this case was deemed to be impractical, paramedics have shown a favorable attitude towards the practical applications of Google Glass should this issue be resolved.
In terms of performance, the sensor platform was able to accurately read the required parameters with a low disconnection rate and rapid recovery when such disconnection errors occurred. The mobile application was able to receive the data at a fast rate, perform calculations, and send the data to the cloud without major problems. It was able to provide the data to the cloud in real time during approximately 98% of the transfer.
The Web application was able to show the information sent by the mobile device and update it in real time, allowing the paramedic to track the state of the patient efficiently while the transfer was made. Requirements for this component included the upkeep of several simultaneous ambulance transfers, each one sending data at a high transfer rate. Using a NoSQL database increased the performance of the application significantly.
In terms of usability, both the mobile and Web applications provided the information in a way that was easy to read for paramedics, and they are expected to be useful for conducting future studies. With regard to the sensor platform, it was found that the sensor wires were rather short and that extending them can improve usability.
Our current prototype fulfills all the requirements to stand on its own as an MVP. Unfortunately, we have so far been unable to move forward towards real applications due to the lack of medical certification of our embedded sensors. Due to this, we have been unable to proceed with practical tests as there are ethical and legal concerns amongst hospital administrators. However, it must be stressed that our tests have shown very little variation between our equipment and that used by SAMU’s ambulances. In theory, they should produce similar results.
In the future, we hope to integrate approved medical equipment in order to make this final step. Additionally, we expect to include more wireless sensors in the system in order to broaden the benefits of the platform. 12-channel ECG, for example, is widely used by paramedics and doctors to help diagnose a patient. By using the available hardware in today’s smartphones, we should also be able to add real-time conferencing functionalities whenever possible. With additional work, we can expect to make this system affordable and robust enough to be included in any ambulance and flexible enough to be connected to several emergency systems. One in particular we are currently studying is the interregional transfer system. It is often the case in southern Chile that there is no road access to some of the more remote locations. In dire situations (natural catastrophes, industrial accidents), ambulances become unavailable due to the collapse of SAMU in the face of a large influx of patients. For instance, on September 16, 2015, an 8.4 magnitude earthquake hit northern Chile. Urban emergency transportation vehicles were insufficient to attend to all the injured and airplanes had to be used as a last resort to carry the wounded (see Figure 13). The use of air and sea transportation vehicles in these kinds of scenarios is not uncommon, yet obviously there is no Internet access through conventional mobile networks in such situations. As a possible solution, we are looking into satellite networks in order to circumvent this constraint and incorporate this platform in airplanes and ships.
In summary, we believe that the evidence obtained from research data generated within real transfers can increase the quality, effectiveness, and efficiency of decisions in patient care. Based on epidemiological needs and prevalence, we identify a need to create risk profiles of patients treated in the health system, which would allow us to characterize risk groups and develop strategies aimed at preventing health problems and complications during transfers. A cloud service information database built on top of predictive analysis solutions will quickly identify the groups most at risk, such as patients in extreme old age, generating new severity scales for such groups.
Disclosure
The present paper is an extended and revised version of a paper presented at the 9th International Conference on Ubiquitous Computing and Ambient Intelligence (UCAmI 2015) [31].
Competing Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgments
This work was partially supported by VRI-PUC Interdisciplinary Grant no. 03/2013, FONIS 2014 SA 12I2045 CONICYT, and SAMU. Finally, we would like to thank all students from the Department of Computer Science and Nursing School at Pontificia Universidad Católica de Chile who were involved in this research project.