A telemedicine support for improving medical emergency management

In this paper, we introduce a telemedicine architecture for supporting emergency patient stabilization and patient transportation to a fully equipped health care center. In particular, we focus on the description of a set of mobile apps, designed for supporting data recording and transmission during patient transportation by ambulance. Some of the apps are interfaced to the monitoring devices in the ambulance, and automatically send all the recorded data to a server at the destination center. One additional app enables the travelling personnel to input and transmit further significant patient data, or comments. At the destination center, the specialist physician is allowed to inspect the data as soon as they are received, possibly providing immediate advice. The exploitation of the apps also allows to maintain the transportation data over time, for medico-legal purposes, or to perform a-posteriori analyses. Some first evaluation results are discussed in the paper. Received on 28 November 2017; accepted on 14 December 2017; published on 19 December 2017


Introduction
Patients experiencing a medical emergency (e.g., stroke patients, pre-term born babies, or accident victims) are normally taken to the closest hospital structure (admission center henceforth), which might be insufficiently equipped, in terms of human or instrumental resources.In these situations, the patient needs to be (1) stabilized, and (2) carried to a larger and more suitable health care center (hub center henceforth), where specialized physicians and all needed diagnostic/therapeutic devices are available.
Both tasks (1) and ( 2) above are critical, since the final patient health status strongly depends on these first phases of his/her recovery.In task (1), it is important that the available physicians implement the correct stabilization process: unfortunately, the admission center physicians are not always specialists in the field (e.g., a neurologist is not available at all hospitals).As a consequence, the actual stabilization process may be sub-optimal.In task (2), the patient is carried by ambulance, and driven to the hub center.During the journey, a specialist physician (e.g., a neurologist) is typically not present; assistance is usually provided by paramedics and/or emergency medicine doctors.The patient is continuously monitored by means of proper instruments available on the ambulance (such as ECG or blood pressure monitor).However, the monitored data are not automatically recorded.Therefore, they cannot be inspected/analyzed a posteriori.Moreover, they are not accessible in real time by the hub center.
We have designed a telemedicine architecture able to overcome the strong geographical, technological and logistic limitations illustrated above, in order to provide citizens with a much higher quality of service in case of a medical emergency.
By means of the telemedicine system, both tasks (1) and ( 2) can be supported.In particular, as regards task (1), the exploitation of webcams and other technological devices enables the expert physician, residing at the hub center, to visualize the patient conditions, and to supervise the stabilization procedure steps being executed at the admission center.As regards task (2), we have implemented a set of mobile apps, designed for supporting data recording and transmission during the journey by ambulance.Some apps are directly interfaced to the monitoring devices in the ambulance, and automatically send all the recorded data to a server at the hub center.One additional app enables the travelling personnel to input and transmit further significant patient data, or comments.At the hub center, the specialist physician is allowed to inspect the data as soon as they are received, possibly providing immediate advice.The exploitation of the apps also allows to maintain the transportation data over time, for medicolegal purposes, or to perform a-posteriori analyses.
In the following, we will present the details of the system, focusing on our support to task (2), where some first evaluation results, collected in collaboration with the Neonatal Intensive Care Unit (NICU) of Alessandria Children Hospital, Italy, are already available.

System architecture
Figure 1 illustrates the architecture of our telemedicine system.Since in our scenario there are different users, both stationary (i.e., the physician at the hub center) and mobile (i.e., the physician in the ambulance), we decide to exploit the most recent distributed system architecture, called Fog Computing [1].As a matter of the fact, this new architecture is designed for applications that (i) require very low and predictable latency, (ii) are geo-distributed, and (iii) run on mobile devices.It is worth noting that the Fog complements the Cloud [2], it does not substitute it.Interestingly, recently, architectures for storing and analyzing medical data in fog computing [3] have been proposed in combination with the usage of mobile devices, which allow the user to send/receive data in real time without any particular equipment and/or knowledge.Specifically, this new computing paradigm integrates the cloud computing into the mobile environment and overcomes obstacles related to performance (e.g., battery life, storage, and bandwidth), environment (e.g., heterogeneity, scalability, and availability), and security (e.g., reliability and privacy) issues.In particular, the approaches in [4] and [5] deal with bandwidth issues.They propose solutions to share the limited bandwidth among mobile users.As for security/integrity/confidentiality issues, a classical solution [6] consists of three main components: a mobile device, a web and storage service and a trusted third party.This third party is in charge of running a trusted crypto co-processor which generates a Message Authentication Code (MAC).Thanks to the MAC, every request from the user to read/write data on cloud storage is properly authenticated and, at any time, it is possible to validate the integrity of any file, collection of files or the whole file system stored in the cloud.In our approach, we have adopted the technological solutions illustrated above.
By means of our framework, the expert physician at the hub center, exploiting a set of webcams and of videoconference tools, is enabled to visualize all the steps of the stabilization process (task 1) being implemented at the admission center.In the case of limited knowledge or resource availability, the stabilization process might be sub-optimal.In this situation, the expert physician can provide her/his advice as required.Moreover, s/he can have a complete understanding of the patient's evolution since the very beginning.
After stabilization, the patient is taken to the ambulance for transportation (task 2).During the journey, all monitoring data, and possibly additional comments, are sent to the hub center by a set of mobile apps, installed on tablets or smartphones.Data are therefore accessible in real time from the hub center server interface.In this way, the expert physician can provide suggestions to the travelling personnel, and already has a complete understanding of the patient's situation as soon as s/he arrives at the center.
Figure 2 presents a closer inspection of data communication from the mobile devices to the hub center server, based on the client-server paradigm.The client side is represented by the set of mobile apps we have implemented.The data inputted through the mobile apps are serialized as a JSON string, which is posted to the server.At the server side, data have to be de-serialized, stored in a database, and shown to the user through a web interface.On the server side, therefore, three main components are exploited: (1) a web server (provided by Apache HTTP or Microsoft Windows Server) with (2) a PHP module enabled and (3) a database server (provided by MySQL).The web page is automatically refreshed every five seconds, in order to always show the most recent data during transportation.Indeed, an updated measurement can be send several times during the journey.More specifically, the apps we have implemented can be subdivided into two groups: the device apps and the operator app.
The device apps, directly connected to the medical monitoring devices in the ambulance (e.g., the saturation meter), are used by default, to send all the automatically recorded data to the server side.A smartphone or a tablet, physically connected to the medical monitoring device via RS-232, perform data transmission.
The operator app is more interesting.In this case, data have to be inserted manually by the personnel, and it is meant to be adopted when: • a medical monitoring device is not working or not available in the specific ambulance.In this case, monitoring data normally collected by the device can be entered manually, and the personnel is significantly helped in data entry, thanks to the availability of pre-defined value ranges and value • additional data have to be provided, which are not measured by the medical devices (also in this case, data entry is facilitated by the supports and correctness checks); • personnel wants to send textual notes and comments.
Details on the operator app are provided in the next subsection.

The operator app
The operator app, in its current version, has been realized to monitor the transportation of pre-term born babies.
Pre-term born babies are very often critical patients, who need intensive care.If a baby is born at an insufficiently equipped hospital, s/he has to be moved to a hospital equipped with a Neonatal Intensive Care Unit (NICU) [7].Transportation may also be required if the baby, possibly already cared at the NICU, needs a specific intervention, that can be performed only at a larger or more specialized clinical center.
The clinical conditions of the baby to be transported may require ventilation assistance during the journey.Three different types of mechanical ventilations exist, each of them requiring specific parameter settings.Different transportation types must therefore be considered.
The operator app is meant to be exploited in very critical situations, where the user has higher priorities with respect to data entry.At the same time, key transportation data are extremely useful for the specialist, and of course need to be correct.Given these goals, the mobile app has been designed to be very user friendly, very clear, and essential in its graphical design.
As observed above, different types of patients may be transported: those requiring mechanical ventilation, and those who are able to breathe autonomously.In order to minimize the number of data to be inserted, and to avoid mistakes, the app immediately asks to select whether the patient has to be ventilated or not.In case of ventilation, the user will further set the correct ventilation type.In this way, instrumental setting data will be required only in the appropriate cases.
Overall, the parameters to be inputted have been selected by our medical collaborators, on the basis of domain knowledge.
Every data entry operation has been customized on the basis of the type of data being inputted, in order to make it as fast and simple as possible, as illustrated in Figure 3.The figure presents three different activities of the operator app, that allow the user to input some data for a non-ventilated transportation.

Figure 2. Data communication during transportation
In Figure 3(a), heart frequency is being inputted.In our application domain, the exact value of heart frequency is not of interest: only the range needs to be specified.To this end, a set of pre-defined ranges are shown to the user, who will just have to choose one of them without digitizing any number.Pre-defined ranges have been defined on the basis of medical knowledge as well.
In the second activity (Figure 3(b)), oxygen saturation has to be inserted.The admissibility range (21%-100%) is reminded to the user, but s/he has then to insert a specific numeric value.To this end, a numeric keyboard is activated.
It is worth noting that consistency controls are also executed in this case, since, as observed above, transportation data always need to be correct.If the digitized number is outside the admissibility range, an error message will appear, in order to allow the user to introduce the correct value.
Finally, in the third case (Figure 3(c)), additional textual notes can be inserted.In this case, an alphanumeric keyboard with auto-completion is activated.
When data have been sent to the server, the user is notified by a toast message, i.e., a notification message that shows for a few seconds and then fades away.

Evaluation results
The subsystem of our telemedicine architecture meant to support the transportation task is currently being used at the NICU of Alessandria Children Hospital, Italy.The NICU has 7 beds, and usually performs more than 150 transportations a year.During the first six months of usage, the system has always shown reliability and timeliness of data transmission from the client to the server side.
It is difficult to assess an improvement of clinical outcomes due to exploitation of our tool.Indeed, the number of patients being transported by the personnel of Alessandria is relatively small (47 in the period at hand); secondly, the majority of babies experienced very serious pathologies, whose effects cannot be easily mitigated just by a prompt and correct data transmission, which is important, but often not sufficient to ameliorate their clinical conditions.
On the other hand, we were able to identify a clear advantage from the organizational and economical viewpoint.In particular, knowing the details of the patient condition in real time (i.e., during transportation) allowed the NICU team an early and optimal bedside set-up, thus reducing the time-window for bedside preparation and the extra-costs in terms of un-needed equipment, such as respiratory support.Bearing in mind that the costs for a respiratory set for invasive/non-invasive ventilation can vary from 700 to 2000 euros, the capability of choosing the adequate equipment set-up permitted the NICU to avoid time and money waste.Specifically, in the period under examination, the NICU was able to save about 6000 euros.

Conclusions and future work
In this paper we have described a telemedicine system for supporting emergency patient stabilization and transportation to a fully equipped health care center.The system includes a set of apps studied to support data communication during patient transportation by ambulance.In particular, the device apps automatically send the data monitored by the medical instruments, while the operator app allows the ambulance personnel to insert additional patient data or comments, and immediately send them to the hub center, thus substituting the extremely incomplete paper log that is currently deployed in many real settings (at least in Italy).The operator app has been designed to  Our framework is currently in use at the NICU of Alessandria Children Hospital, Italy, where it has already provided organizational and economical improvements.The data available so far, however, are not quantitatively sufficient to draw statistical tests.Indeed, the system has been used for a few months, and the number of patient transportations in our application domain is rather limited.A statistical study will be conducted as a future work, as soon as more data will be collected.
In the future, we also foresee a number of possible developments of our system.
As regards task (1), in the future we plan adopt some process mining and process analysis techniques [8] to improve stabilization.In particular, we plan to mine the actual process implemented locally at the admission center, in order to assess its quality and identify possible malpractices and limitations through proper comparisons with reference guidelines and stabilization best practices.We will define novel metrics to enable process comparison, by extending works in the area of graph similarity calculation [9], in order to realize a knowledge-intensive and semantic approach, along the lines we described in [10].
As regards task (2), monitoring data are in the form of time series.Storing this information in a compact form, and efficiently retrieving it, is fundamental, given the huge amount of data, which may require the management of typical big data issues.We plan to implement time series data summarization and efficient querying strategies, mainly exploring Temporal Abstraction (TA) [11].Through TA, we will move towards a qualitative summarization strategy, which is based on domain knowledge and maintains a clear mapping between original and abstracted data.The possibility to view a summarized time series, or to perform a query, will be provided during transportation, for real time (remote) supervision.Moreover, it will be provided for a-posteriori analysis.Indeed, data will be maintained also after the emergency management phase, and will provide a database of previous "cases", to be exploited in the future.Novel similarity-based case retrieval [12] and efficient querying techniques will be defined, considering that data are highly dimensional.Case retrieval will be very useful for off-line problem solving, a-posteriori evaluation of specific situations, and, generally, experiential knowledge management over time.

Figure 3 .
Figure 3. Snapshots of 3 activities in the operator app