Smart hospital emergency system

Abstract

In recent years, the UK’s emergency call and response has shown elements of great strain as of today. The strain on emergency call systems estimated by a 9 million calls (including both landline and mobile) made in 2014 alone. Coupled with an increasing population and cuts in government funding, this has resulted in lower percentages of emergency response vehicles at hand and longer response times. In this paper, we highlight the main challenges of emergency services and overview of previous solutions. In addition, we propose a new system call Smart Hospital Emergency System (SHES). The main aim of SHES is to save lives through improving communications between patient and emergency services. Utilising the latest of technologies and algorithms within SHES is aiming to increase emergency communication throughput, while reducing emergency call systems issues and making the process of emergency response more efficient. Utilising health data held within a personal smartphone, and internal tracked data (GPU, Accelerometer, Gyroscope etc.), SHES aims to process the mentioned data efficiently, and securely, through automatic communications with emergency services, ultimately reducing communication bottlenecks. Live video-streaming through real-time video communication protocols is also a focus of SHES to improve initial communications between emergency services and patients. A prototype of this system has been developed. The system has been evaluated by a preliminary usability, reliability, and communication performance study.

1 Introduction

Improving the efficiency of healthcare and biomedical-systems is one of the considerable goals of our modern society. Hence, it become essential to delivere a high quality healthcare to patients while reducing the associate costs of healthcare services and, meantime, tackle the issue of nursing staff shortage [3]. In fact, in the 21st century’s Information age, we use computational facilities of every type for different purposes on a daily basis (e.g., controlling home appliances and monitoring energy use), which led to producing and transmitting huge amounts of personal data every second. Unfortunately, despite the rapid increase in technology, finding where and when someone in an emergency is still an outstanding problem [25]. This open problem needs additional dedicated work to be resolved, due to the fact that unless an actual caller is able to tell the emergency call operator where they are, the best that can be done is to narrow down the patient’s location to a small area of a few square miles to be searched. We have looked into this problem broadly, finding methods that are being researched or in the early development giving them critical analyse of their methods.

During 2014-15 over 9 million calls were received by emergency switchboards with an increase of 515,506 compared to the previous years indicating a call volume growth of 6.1% in just one year [31]. With a rising population and budget cuts it is reported that thousands of emergency calls go unanswered every year as operators try to cope with a high demand and limited resources [22, 24]. Due to UK government austerity measures which are predicted to continue to 2020 to reduce the deficit [27] it is unlikely that emergency services will receive further funding. Therefore, the motivation of using technologies to save time and money are highly in demand. In addition, its estimated that 75% of all calls received by emergency operators are considered non-emergency calls. This equated to around 5.7 million calls in 2011 [4]. Reducing the non-emergency calls volume is one area that will be focused upon. The term ‘Non-Emergency’ refers not only to cases where an event is misidentified as an emergency, but also prank calls and accidental dials. In a standard emergency call, operators will ask three main questions to callers in this order, “What service is required?”, “Where are you calling from?” and “What is your emergency?” [18]. Each of these questions pose problems for the operator if patients cannot give an accurate answer, for instance, if patients cannot provide their location or condition, the operator will not be able to send the correct personnel to correct location, thus the source of much wasted time. These three main questions will be the focus of the proposed features within the SHES system.

The major issues with the call system, such as unanswered emergency calls, which directly affect human life, are extremely important and need to be addressed urgently with a viable solution. For the emergency call service to continue working, it is therefore vital that the service works as efficiently as possible, which means that it is able to handle a considerable number of emergency requests with minimal delay (within few seconds). Our system will attempt to address the various problems with the current emergency call systems along with the development of a emergency services’ mobile application call SHES. The app connected to the emergency and accident (E&A) units, thus, on user’s side, they will be permit to send enquiries and requesting an ambulance, on the hospital side, doctors are able to respond to a patient’s enquiry and send ambulance in case of emergency. In addition, the system will make use of new technologies such as WebRTC [14, 19], which supports web-based videocommunication. The feature will enhance the system usability by providing built-in two-way communication between patients and doctors, to discuss urgent cases or provide them with first aid instruction remotely. SHES is proposed for A&E units in hospitals, hence, a prototype of the system has been implemented upon studying the current call systems and the issues associate with them, thus, its validated by means of a simple proof of concept representative for the main functionalities and capabilities of the proposed system.

The rest of the paper is organised as follows; In Section 2 the background and limitations of existing systems are discussed along with related work is analysed. The theory of the proposed SHES and its architecture are outlined in Section 3. According to the proposed SHES framework and architecture, we implement a prototype to show the feasibility of the SHES in Section 4. Results and evaluations of SHES are presented in Section 5. Finally, we summarize this paper and potential future work in Section 6.

2 Background and related research

In this section, we outline the main issues related to the subject matter including an introduction to emergency systems, what are their functions, and problems are associated with them. Furthermore, we research a related work and solutions to the emergency systems along with state of the art systems and technologies in this field.

2.1 Emergency call systems

After the invention of telephones in 1876 [7], it suddenly became possible to call for help from great distances by talking to an operator who would re-direct your call to the requested service/department or send help straightaway. As phone networks grew and became more complex and complicated, a need for dedicated emergency numbers became apparent. London was the first location to create a dedicated emergency phone number [8] and as of today essentially every country worldwide has at least one emergency phone number.

In 2002, around 7.1 million accidental calls were made to emergency services [26]. Since the development of smart phones, this figure has dropped massively to just 284,327 in 2009. Although this decrease is a huge step forward, accidental dialling - sometimes called pocket dialling - is a common problem that must be reduced. Making it difficult to dial the number is also problematic as the number in practice needs to be easy to dial in emergencies.

During the 2014-15 period, over 9 million calls were received by the emergency switchboards with an increase of 515.506 compared to the previous year, indicating a call volume growth of 6.1% [31] With a rising population and budget cuts, it is reported that thousands of emergency calls go unanswered every year as operators try to cope with high demands and limited resources [22, 24].

Historically, the emergency service number 999 was selected during the use of rotary phones in order to make it more difficult to accidentally dial the number. Ironically, with the rise of push-button phones, and more recently touch screen, it has become much easier to accidentally dial the emergency number 999 due to its repeating digits. Our proposed application will have mechanisms put in place, which will make accidental dialling less likely while still taking into consideration the importance of being able to easily dial a number. We will achieve this by taking into account factors such as button placement and human response times.

2.2 Call system issues

In this section, we aim to outline the many problems relating to the emergency call pipeline and explain how they affect the system in terms of being problematic or causing inefficiencies. The difficulties with call systems start when an operator tries to find answers for the most frequent questions, “What service is required?” - “Where are you calling from?” and “What is your emergency?”, hence emergency unit responses will depend highly on where, and what the emergency case is, as responses are priorities according these values. For example, a patients with chronic condition would have higher priority for emergency service than a patient in pain. Therefore, timely and accurate answers for the above questions are essential to potentially save lives.

Caller Location -:

One of the most vital pieces of information requested during an emergency is the caller’s location as it allows the operator to know where to send help. The faster this information is retrieved, the faster the response. In some cases, it could be difficult for callers to give their location verbally. In this case, operators must have other methods to trace a caller’s location. Calls made from a land-line are the easiest to trace because phone numbers are registered to a specific address, mobile phones on the other hand, which make up 60% of all emergency calls, are harder to locate. There are three main ways that a mobile’s current location can be gathered. These are:

Cell Towers -:

As mobile phones use nearby cell towers to transmit and receive calls their location can be narrowed down to the area covered by that specific tower’s signal, which is generally 1-2 miles. More accurate readings can be gained by triangulating a phone’s signal from multiple cell towers.

Global Positioning System (GPS) -:

As more smart-phones than ever now have a built-in GPS transmitter, this feature can be exploited to gather the caller’s location and then sent to the emergency operator. Having a caller’s GPS location which is often rendered to their latitude and longitude would be the most accurate with up to 15 meters of error. An issue with GPS is the limitation of usability due to frequency blackouts. GPS signals work on a frequency which finds it difficult to travel through solid objects such as rooftops and walls, therefore there is no guarantee of it working inside buildings [20].

Wi-Fi -:

Wi-Fi Positioning System (WPS) makes use of Wi-Fi access points to measure a mobile Wi-Fi signal intensity [13, 32]. This system is useful in large urban areas where Wi-Fi signals are common however are less than useful in rural areas that are often Wi-Fi dead zones. However, when it is available, Wi-Fi can be used as a means of transmitting information for devices via the internet. In theory, information such as GPS, coordinates could be shared with medical professionals.

Pranksters and Hoaxes -:

Of the non-emergency calls received by operators, malicious calls are by far the costliest with emergency vehicles having to respond to fabricated events such as a non-existent fire. In 2003, British Telecom estimated that these fake calls cost taxpayers £32 million [9]. The anonymous nature of making fake calls appears to be a major factor for pranksters as their identity is concealed and therefore they may act in ways they may not do so otherwise. This type of disconnect is known as the OnlineDisinhibition effect. By removing the anonymity of callers, it is therefore reasonable to suggest that people will be less likely to make fake calls.

Choosing the Right Number -:

To make an emergency call from anywhere in the world, a caller must first know which emergency service they need and that service’s phone number. From an international perspective, this can be difficult as emergency numbers are not standardised globally with the UK using 999, the U.S using 911 and some countries having separate numbers for police, ambulance and fire rescue. Also for less serious situations, numerous numbers exist, for example in the U.K, the following numbers are available:

• 1. 999/112/911 - Emergency number (Inc. Police, Fire, Ambulance, and etc.).

• 2. 111 - Non-emergency medical.

• 3. 101 - Non-emergency police.

To reduce the over use of the 999 call system alternative non-emergency numbers have been set-up which offer telephone advice. However, there is no evidence that these numbers reduce 999 call volume [17]. A possible cause of this may be a lack of awareness about the different numbers although it is suggested providing telephone advice rather than dispatching response vehicles is a good alternative response for non-serious calls [21]. It is clear that better education about what situations to make a call and who to call appears to be the main solutions to this problem. The proposed development will seek to have all the different service numbers programmed in and by using a series of questions can help users determine if they need to call and if so the correct number that they should call. The aim of this is to help filter out or re-direct non-serious emergencies, freeing up room for real emergencies.

2.3 Related work

In this subsection, we have carried out research revolved around the methods that are currently being used to solve the problems of getting a caller’s location. Emergency call systems have improved greatly from their early beginnings, as new technologies have been developed, so too has the system’s ability to gather more accurate information and make the higher choices. As it stands current UK emergency systems require the caller to give their current location so as the operator may know where to send help. This method has not changed since the inception of emergency call systems despite technologies for gathering location information such as GPS being commercially available since the late 90s. Although that is not to say a caller’s response is the only method used to gather their location. Emergency call operators can narrow the caller’s location down to a specific area, generally a few miles depending on their distance from cell towers. This is largely inaccurate and means the emergency response vehicle must search a potentially large area.

Researchers gives more attention to the push and pull services models and strategies in which helps in narrowing patient’s location. Such push-pull services are mainly activated by an event such as a specific area is entered or a timer is reached [10, 33]. Huh et al. [10] proposed a system which allows senior citizens to locate an appropriate medical facility by using mobile GPS location’s information together with a mobile push system. In addition, they monitors the user with the Bluetooth beacons, thus the system autonomously estimates the current coordinates of user with a GPS or a network information system to locate the nearest medical centres or clinics from the database where the information regarding the location of medical facilities which has been stored in advance [10]. Zhu et al. [33] proposed an advanced architecture for push service by combining location with the presence services to push the infotainment and info commercial via 3G wireless systems [10]. Hussain et al. [11], propose an IoT cloud solution for Smart Cities that monitors users’ physical parameters within a Body Area Network (BAN) in which a virtual community of resources and on-line social networks play an important role [15]. Hussain et al. [11] proposed model is based on people-centric sensing framework for the healthcare of elderly and disabled people. Such platform is aimed to monitor health of the elderly and disabled person and provide them with a service oriented emergency response in case of abnormal health conditions [11]. Catarinucci et al. [3] proposed an IoT-aware smart hospital system (SHS) that is able to guarantee innovative services for the automatic monitoring and tracking of patients, personnel, and biomedical devices within hospitals and nursing institutes, by exploiting the potentialities offered by the joint use of different technologies and standards, such as RFID, WSN, smart mobile, 6LoWPAN, and Constrained Application Protocol (CoAP) [3], however, they have only considered a hospital based monitoring, therefore, there is no call for action in the case of emergency.

Requesting Emergency Services via SMS [6], since late 2009 is has been possible to request emergency help using SMS text messaging [6]. The aim of this service was to allow the deaf, hard of hearing and speech-impaired to request help. The system however has a number of problems which will limit its usability, for example phones need to be pre-registered first in order to send messages. Some other limiting features are; i) Slower communication compared to speech, ii) Difficult to type if caller is injured or panicking, and iii) Individual SMS messages are limited to 160 characters.

Advanced Mobile Location (AML) [2] proosed to exploits the use of SMS messaging and mobile-based location to find patient’s location through a text messaging system. AML is a relatively new system that is being tested across Europe after having been partially implemented in the U.K and Estonia with positive feedbacks. The system was developed by BT, EE and HTC [2] but currently not all mobile and mobile networks support the system as the functionality is dependent whether or not they choose to implement it with the operating system [2]. Although the biggest networks such as EE, Vodafone, and O2 all support the system around 10-15% of networks do not meaning the system is not universal. In 2016 Google announced that all versions of Android Operating System (OS), over version 2.3 (Gingerbread), would support AML. Around 50.6% of all UK smart-phones use Android leaving a sizeable minority with the feature. Furthermore, as mentioned, this work will ultimately depend on the network provider. As our application is third-party software, the phone’s OS does not need to have the function built-in, making it network independent. Similar applications can be built for different mobile operating systems, providing additional implementations for alternative OS’s. Another feature not found in AML is the ability to send additional useful information provided by the user. For example, as users name, next of kin, previous medical problems. However, it does not support live video chat communication with paramedics for remote treatment, which is significant for patients in remote area.

In Case of Emergence (ICE) [12] is one of the top three medical applications in the UK, Canada, Norway, and Denmark. The ICE app is the most downloaded app in Australia and Sweden in the Medical category. This shows how popular the application is in these countries. This app is available for both iOS phone and Android phone [12]. In Case of Emergency application puts user emergency information on the lock screen wallpaper, including emergency contact number specified by the user. ICE also records additional data, such as medical condition, medication, and insurance information to be use in case of emergency. However, even though ICE has some good reviews, ICE does not work as fully functional emergency system as it does not connect people to emergency units or provide user location. Nevertheless, some users found it is pointless to have it on the lock screen if still required pin to get into the data by the paramedics.

First Aid American Red Cross [1] is the official American Red Cross First Aid app puts expert advice for everyday emergencies, by watching videos, interactive quizzes, and simple step-by-step advice for first aid [1]. The app is available free for Android and iOS devises, and the main features are; full integration with 9-1-1, so you can call EMS from the application at any time, supports multiple languages, and provides videos and animations, which is aimed at making learning first aid fun and easy. The limitation of this application is that no actual emeregnecy helps provided in case of emergency. In other words, it takes users (i.e., patietns) a long time to get to very limited information about the patient. It also does not provide patient location or condition to paramedics. In addition, from users review, found that it is inconvenience to read the instructions of first aid animations and videos [1] in the situation of emergency, as this is counter-intuitive with patients need immediate help and/or advice.

Emergency Medical Centre Locator (EMCL) [16], this system has been devloped to help patients in finding the closest specialised emergency medical centre. The app focuses on six special categories; trauma, stroke, eye, pediatric, cardiac, and burn [16]. EMCL available for iOS only. The description and the name of the application sounds like we can find a nearby emergency unit for a specific case, but it does not work in this way. The user should search all the results which appear and select the nearest centre suitable for their emergency case. In fact, that functionality would not be helpful in an emergency situation as it is time consuming and inconvenient for a patient whom needs immediate help. Nevertheless, no actual emergency help is given, the application does not provide any facilities to the patient trigger emergency call for help and cannot communicate with paramedic.

3 Proposed SHES system

The proposed Smart Hospital Emergency System (SHES), aims to make use of the technology embedded within smart-phones (e.g., sensors and location services) to increase emergency service efficiency by providing faster response time. The main purpose of SHES is to automatically send patients information in lieu of using the conventional method in which the callers relays their information verbally on the phone. The overall aim of SHES will be to reduce the response time by which emergency calls are made and received by streamlining the number of tasks that are involved in the current process. By simplifying these steps, the expected result should be; a faster response time, greater call turnover for operators, and increased efficiency when gathering a caller’s details.

The methodology we adopt in developing the SHES is based on investigating the issues related to the call system as well as features that can be developed to improve the traditional approach of calling for emergency. Therefore, we investigate systems implemented for patient and operator communications and systems used by both parties for gathering data to help aid both parties, which involves the mobile applications used by the caller (i.e. patients) and the web-platforms used by the operator (i.e. doctors and paramedic). Figure 1a shows the main steps that are carried out by the system when collecting and processing necessary information from the callers. Looking at whom would use the system, we have identified three members who play a role within the system (Fig. 1b). Each of these users groups,have different things that they want from the system. They will also utilise and use the system in different ways. Hence, the user groups roles as follow:

• 1. The Caller is the person requesting help via the SHES.

• 2. The Operator is the person being contacted for help.

• 3. The Responder is the person who will go to help the caller.

Fig. 1

SHES Work-flow & Users

The system collects data in two ways. First way, the system collects patients data through the mobile application, and second way, system collects operator data through the operator web-platform. After data has been collected, it is sent to the data-center for processing and made it available for the operator to access it anywhere and at any-time. The general flow of the data can be seen as two-way flow between patient-platform and operators-platform, or more accurately should including the data-center layer i.e., patients⇔data-center⇔operator. The flowchart in Fig. 2 shows the process of requesting ambulance, in which, the logic of running the SHES application, at first, when patient launches the SHES application its checks whether it is first-time user or not. If first-time user, then registration process become mandatory so that system knows the user’s unique identifier (e.g. NHS Number) to be use during emergency requesting process. Also, this could help preventing malicious request as users can be tracked trough their mobile location. After user is identified, normal procedures of taking patients emergency and placing the request will be described in more details in Algorithm 1.

Fig. 2

Flowchart to demonstrate the ambulance requesting service

It is expected that within the SHES mobile app, users will be able to automatically synchronise their info such as name, age, status, and current GPS coordinates. Thus, all these data is transferred over the internet (i.e., via Wi-Fi, 3G, 4G, or etc) to a data-centres where all data will be stored and become available for use/access by authorised healthcare giver. And ultimately, a web-platform (aka, operator platform) is connected to the data-center to display patients requests. In the operator platform, it is expected to display different types of information/data, but mainly the user’s identification (i.e., NHS Number), GPS data, and other related data to patient status. In addition, this data should be accurately presented, for example, GPS coordination for the patients location should be presented on a map view, while the symptom data presented with appropriate charts, such as line-char for presenting heart-rate.

3.1 Theory of SHES

SHES is intended to be an emergency response system so we must ensure that like any other emergency system that it has as little downtime as possible. A system with low availability would not be appropriate for situations in where loss of life may be a factor. As the system is handling a potentially sensitive personal data, it is important that the system acts in a responsible way by ensuring that every effort is made to keep user information safe. Some examples of this could be requiring users to login/register to use the service. Furthermore, we must also ensure that the server, in which our data-center is located, is effectively protected with a password.

Design mobile application for healthcare can very critical as there are a number of guidelines which need to be followed for effective mHealth applications in term of patient data security and legalisation [34]. Poor application design will lead to security and usability issues that can lead to application failure. Therefore, it is important that we implement a series of reasonable measures to protect our user’s sensitive data from being stolen from either our data-center or through the process of transmitting info from/to patient’s mobile application. To meet our applications security requirements, we plan to integrate an account-based feature which requires users to first create an account that can later be used to access the SHES via a user-name and password. Also, intended to follow the Health Level Seven¹(HL7) standers in the way the SHES system integrate, share and retrieve of any electronic health related data. in addition, the data is end-to-end encrypted (E2EE), i.e., from patients mobile app to hospital platform the data is encrypted.

On the patients side, the SHES app is planned to have numerous capabilities, which relate to gathering patient’s information. Table 1 shows the general requirements of three users of the system. Apart from the standard basic information such as name, age and current location, more specific information will be transmitted. Such extra data will include the patient’s vitals that is information like their heart-rate or blood sugar levels. Also, an optional choice of including photo with the ambulance request functionality, so that paramedic can make early arrangements to save patients. In addition, small pieces of information like these aim to give both operators and responders a better understanding of the patient’s current situation and make better decisions about their treatments. As our application will involve the handling of personal data, some of which being of a sensitive nature, our system will have a provision in place to protect a user’s information from being stolen. For this we plan to install a login feature which will require users to first sign-up for an account, provide some basic information, and then enable the app’s main call feature. Another requirement will be for the ability to instigate a video call from within the app to make both verbal and visual communication possible with an emergency operator, using web-based real-time Communication. For the reail-time live Communication we adopt Google WebRTC API [14, 19] which support media sharing, including the transmission of video and voice along with other medical data, such as ECG. Based upon the issues outlined on patients side, we incorporate the following features in SHES mobile application (i.e., patient platform):

• patient’s data synchronisation to A&E operators platform.

• A mechanism to reduce accidental dialling.

• Increased accessibility for disabled callers.

• Advice guide on when, and who to call for help.

• Finally, the ability to make video calls.

Table 1 SHES Requirements, based on users group

Moreover, the WebRTC supports a real-time multimedia communication technology that allows web-to-web communications without depending on any internal or external plug-ins. Thus, real-time web-based video conferencing can be achieved by only using the HTML5 label and JavaScript APIs for data aggregation and transmission alongside with a dedicated server that support live communications. The main components/ingredient of WebRTC API are four main functions [23, 28, 30], these are; i) Get User Media function which allows a web-based platform to access the media devices, such as camera and microphone, in order to capture the media. ii) RTC Peer Connection function to set-up the audio and video communications. iii) RTC Data Channel which allows the web platforms sharing the media data via peer-to-peer web-platforms, thus this could support multi-channel for involving multiple operators (e.g., more than one doctor attending the call). iv) Get Stats function allows the web platform to retrieve a statistics about the WebRTC active sessions.

On the operator side, operators can have the right to use the a web-platform to view patient details, attend upcoming calls, and the key task of getting the information (location coordination, case information) of the emergency request made from mobile application from people in need of an ambulance. The web-platform should be comparable to run in most standard web browsers and without any observable lagging or sudden crashing to increase the usability of the system, instead of restricting users with a particulate platform. To achieve this, we must make sure that our website can perform as expected on a computer with average computing power. A web portal which can only run on high powered computers will limit the developments range by restricting its usage. Furthermore, the web-platform should be able to perform within the majority of web browser avoiding the use of features that are not widely used such as some features of HTML5, and this essential to insure the video communication run smoothly for both caller and operator platforms. From research, it appears that the most common web browser is Google Chrome over 50% of the market share, so we should at the bare minimum aim for perfect functionality with this browser. For the web platform the primary requirement is, as mentioned previously, is to retrieve information from the data-center and display it on screen for operators. For example, the coordinate data should appear as an overlay on a Google Maps API which will indicate the caller’s location and thus allow them to be tracked. The other pieces of information, name, age, and gender, should also be pulled from the data-center and displayed. On the web platform contact section, the plan is for a number of fields to be populated automatically with patient data giving the operator an overview of all patients. It is also expected the profile photos that the patient takes appear alongside the data as a means to identifying them. Lastly as with the mobile app the website should be able to receive video calls from patients.

3.2 SHES architecture

SHES consist of a mobile based application connected to the hospital platform (i.e., emergency and accident unit), which will respond to patients enquiries and ambulance services requests. The application will be used mainly for two purposes; either for requesting an ambulance in case of emergency, or to regularly monitor patients symptoms and record it for future use (such as blood pressure, heart-rate and etc.). Symptoms records features helps doctors to remotely check patients status and follow up procedures, especially for patients with a chronic illness. Figure 3 shows the SHES architecture, including three layers - patients side, data-center, and doctor platform. These layers components and functionalities as follow:

• 1. Patients side: the main components of this layer is a smart-phone with SHES app installed. This App use by patients in case of emergency to request of ambulance. Thus, the App will make use of some of the built in sensors to provide data such as location coordination’s, without patients with finding their location at the time. In addition, the App provided with symptoms recorder that use to record some symptoms (e.g., Heart-rate) to built electronic health (e-Health) diary for each patients. These e-Health data is valuable during the remote check-up/treatment feature provided by SHES, thus, through the remote check-up/treatment facilities doctors and/or authorised healthcare-giver can access the patient’s symptom data via the e-Health so they can make petter decision upon these data. The remote check-up/treatment facility run through the two-way video chat provided in both patients and doctors platforms.

• 2. Data-center is use to to store patients data. It receive patient’s data from their smart-phone app over the Internet and sorted as under patient’s records tables, then it will be available for doctors and/or authorised healthcare-giver to monitoring make use of these data (i.e., ambulance requests, and remote check-up/treatment facility). In addition, all data analysis and processing will be held in this layer for any disorder detecting in patient’s data by setting a threshold for symptoms. Thus, abnormal data will be categorizing based on patient status and diseases, then report it either to patient’s doctor or emergency unit or both depend on patient status.

• 3. Hospital/Doctors platform to monitor upcoming ambulances requests and monitoring of e-Heath data by authorised healthcare-giver. Data synchronization in the web-platform in real-time to keep doctors with up-to-date data about patient’s status. Also doctor can guide paramedic to take early actions in case of emergency before patient condition getting worse. This could and prevent hospitalization, which may save some costs.

Fig. 3

SHES System Architecture, from patients app to doctors platform

All information should be transmitted across all layers without any delay to insure having a high performance within the system. Therefore, within SHES all data is been structured, compressed, and decompressed properly and accurately to insure that date transitions are completed in real-time or near real-time as these data are essential to E&A unit to make critical decisions, any mistake may cost life. SHES is an interactive system, which involves interactions with users over two platforms (i.e., patient-platform and operator-platform), thus, keeping both patients and health-giver up to date with their date. The ambulance request Algorithm 1, demonstrate the logic in which the SHES application is follow during the ambulance requesting process. The system start with initiate and checking SHES system services as per line (1&2), then simple authentication steps are taken on system start, to insure that the user is been identified by their NHS number (i.e., logged in) or they will be redirected to registration page as per (Lines 3&16). Then the remaining processes (lines 4-15) is to get user location (i.e., Latitude, and Longitude) and assign the right service to patient upon their location. The desired service and patient’s location is pinpointed to emergency services unit, thus operator can make the necessary arrangements.

4 SHES prototype implementation

In this section, a prototype of SHES has been implemented and validated by means of a simple proof of concept representative for the main functionalities, capabilities, and aspect of the novelty of the SHES compared to traditional call system and available solutions in the literature.

The SHES follows a client/server architecture and involves working of three parts mainly: i) The mobile application where the users (aka patients) can send an emergency requests and establish a live communication for remote treatment via WebRTC. ii) A data-center hosted on a server, where all system and patients data is stored and manipulated accordingly, and iii) The web-platform which functions from the system through which the user (administrator) will display the information of emergency requests made, and will be able to perform other tasks like receiving calls or registering a new patients. Therefore, we should consider the implementation arrangements carries over the three layers of the system.

The firstly part of the developments is data-center allocation and building the structure. Data-center layer include the design and deployment of central database that store all system data, for this layer an allocated Linux server used, with version 10.0.27-MariaDB and compiled for Linux (x86_64). The database has been implemented using MySQL Workbench 6 software and structured query language for performing the creation of tasks. The database consists of five entities linked accordingly. The main entities involved in our SHES database are the patient,administrator and emergency − ambulances entity. The patient entity is further linked with patient’s medical data entities for e-Health records such as heart-rate. Separate e-Health entities allows flexible of expanding the system to any other medical data required for patients in the future,this can be achieve by adding new entity and link it to patient through the identifier (i.g., NHS number). Since that one of our motivation is to eliminate service delays, a proper relation between entities should be initialise at early stages. Therefore, patients entity linked to emergency − ambulances, in which, users (aka patients) can save time during ambulance requesting service, in other word patients can avoid filling pre-initialised data such name, gender and etc., during every request by simply fetch the patients data through the unique identifier (i.e., NHS number) during the request.

The second part of the developments is the SHES app (i.e., patients app). For our SHES prototype app, we decided to use Android development environment for the proof of concept. Therefore, Android’s official Integrated development environment IDE Android Studio which has a series of useful feature for rapid development including good error detection, a WYSIWYG interface and an integrated AVD (Android Virtual Device) manager for testing across multiple devices. Also, an actual Android device (Sony Xperia Z2 - 16 GB) used through the development and testing of the app. Thus, any device can be use to run the SHES app, but should have the following criteria: i) Android Version: 4.1 (Jelly Bean) or Higher, ii) GPS Enabled, and iii) Internet Enabled. Figure 4 show some screen interfaces for the SHES app.

Fig. 4

SHES mobile app interfaces

The third part of the developments is the web-platform (i.e., hospital/doctors platform). The design approach used is an adoption of Two-Panel Selector and List Inlay design pattern. This approach has been considered based on improving the usability of the system thus the user interaction. List Inlay pattern has been used in cases where the list of calls or list of emergency requests had to made available. The Two-Panel Selector approach is used in cases where patient detail search is performed or attending request task is carried out. To further enhance the application iframes have been used in various sections to display the real-time data updated contents, with auto refreshing the frames. The web platform has been designed using several scripting languages including HTML, JavaScript , PHP, MySQL and CSS for styling. The editor used for the purpose is Brackets version 1.9.

Regarding the ethical implications of the system the most apparent issue would be the systems reliance on accessing a user’s personal data. The fact that the system records a user’s whereabouts and keeps a sizeable amount of personal, including medical information and then transmits them raises many privacy concerns. Perhaps more security and privacy of data is outside the scope of this research. Another ethical issue is the possible fallout if the system fails, the system deals with situations in which human life is at risk a failed system could result in loss of life. In terms of how SHES gathers and transmits location data we acknowledge that using our current method there are some limitations which can be resolved. For example, currently our system requires the use of GPS and Wi-Fi technologies which may not always be available on a caller’s device. We therefore feel that additional location gathering methods would need to be available as a contingency option for those without GPS or Wi-Fi. We have mentioned briefly about other technologies that could be used such as send data though SMS instead of Wi-Fi or by using cell towers to triangulate a caller. These options could be also built-in so that the system does not have to rely on just one method. In addition, advance location technologies for indoor navigation also can be considered for future development, such as Visual Positioning Service (VPS), and INivigation [29] for indoor navigation, this feature could enhance usability, and efficiency of the SHES significantly, by providing accurate location for indoor and outdoor coordination.

5 Result and evaluation

This section shows the outcome of the developed system. More precisely, showing whether the presented application has fulfilled the aims set out beforehand for the SHES, by using a series of different testing methods. We used unit-testing, which focuses heavily on the structure of the software system and requires a certain degree of knowledge about SHES internal logic, to demonstrate that the performance of the system is as expected. Android version testing also has been carried out to insure that the app completable with different android versions as shown in Table 2. We were able to do some additional testing via an Android emulator. SHES app built with Android Studio IDE which comes with a built-in Android Virtual Device (AVD) emulator, which allow to test the functionality of the app across different types of Android devices. For example, we can tell the emulator to simulate a mobile phone with x amount of memory or a phone using android versiony. The user groups with different android version in Table 2 asked to evaluate the usability experience of SHES after set of testing on the prototype as per Fig. 5. The users have tested the main functionality of the system under two main scenarios; Scenario 1, testing the media streaming function through the webRTC API between their mobile application and the operator web-platform. While Scenario 2 is testing the ambulance requesting functionality and location finding over different networks, such as 3G, 4G and WIFI. Figure 5a shows the performance results for the users over the two scenarios, thus the finding are categorised under performance outcomes as Success, Success with issue and Fail and it is cleat the prototype has proven performance over both scenarios. After set of experiments, the users are asked to score their usability experience upon using SHES as per Fig. 5b.

Table 2 SHES testing over several android versions

Fig. 5

User usability Analysis

5.1 Ambulance requesting

One of the main functionality of SHES is the ambulance requesting services. Thus, this include gathering and displaying patients data in addition to the location coordination, which involves:

Step 1::

This step consists of initiate the processes of gathering patient data, gathering GPS coordination, and sending the data to the data-center. The outcome of this step is providing all necessary data for the operator. as shown in Fig. 6. The device built-in GPS sensor will use at this stage to gather the location coordination, therefore, will need user permission to perform the task. The app also provided with features that increase the performance of the system by helping user to fill the ambulance requesting form quickly and accurately. For example, the app will suggest to whom is the ambulance required, based-on the logged in user so that data will be fetched automatically without filling it in. Also app provide a pop-up window with list of common emergency situation (e.g., accident, coma, burn, and etc.), in which patients can simple pick their emergency without wasting time explaining the situation.

Step 2::

This step involves sorting and storing the data into the date-center in order to be used on the operator platform.

Step 3::

The last step involves the following actions: retrieving data from the data-center, display the location coordinate of ambulance requests on the operator map as shown in Fig. 7.

Fig. 6

The SHES app during ambulance requesting process

Fig. 7

SHES operator map with patients location

The important parameters to measure during this process is the time require to place an ambulance request and the accuracy of the transmitted data. Therefore, it is important to highlight how the system handle the responses for the stander questions - “What service is required?” “Where are you calling from?” and “What is your emergency?” - required by operators with each request to provide the ideal service. It is clear from Fig. 6 that SHES app can help patients in retrieving answers for all these question with no room for mistake. For example, once patients SHES app to request ambulance, they do not have to worry about pinpoint their location as the app have the mechanism to automatically locate the location coordination (latitude and longitude) and attach it with the request, hence, in this process the answer for “What service is required?” - “Where are you calling from?” has been provided with very simple and quick steps (in most cases it took less than 50 seconds to complete the process). Also by using the pop-up window explained beforehand, they can provide answer for “What is your emergency?”.

5.2 Video communication

One of the important functionality of SHES is the video Communication, which has been included for the remote check-up or treatment. On patient’s side, the patient can make a real-time video communication request to attend a call with the operator (on hospital side) through WebRTC as a web based communication protocol. On operator side, the platform has developed to allow pulling all new video communication requests in real-time within the iframe which has been designed with auto refresh feature that allows call invitations appears on the operator dashboard with no delay. The patients invitation’s requests list is displayed with caller name and id (aka NHS Number) along with invitation acceptance button for attending call invitations. Once the invitation accepted, new session will be created where both patient and operator are subscribed to start the conversation. Moreover, once the communication session is established and both patient and operator are subscribed they can start sharing media and real-time data transmission of voice and video based on the WebRTC APIs which enables the media sharing. Figure 8 shows an example of a video communication between patient (on mobile view) and operator (on web-platform view). The WebRTC suitable for this SHES because WebRTC allows a real-time multimedia sharing through the supports of browser-to-browser communication without the needs for internal or external plug-ins. In addition, it possible to automatically adjust the resolution and bandwidth constraints for video and audio interactions to manage users experience over different networks topology, such as WIFI, 3G/4G, etc.

Fig. 8

Patient and Operator platforms during the Video Communication

5.3 E-health data monitors

An important feature of the SHES is the ability to record patients vital sign and make it available for health-giver. AS mentioned beforehand, the importance of this functionality accrue during the period where limited emergency services available (e.g., in remote-area), thus patients are able to measure their vital sign (such as hear-rate, blood sugar, blood pressure, and etc.) and record it in the app monitor to be send to the specialist doctor. In this research, we are not inventing a vital sign monitor as there are plenty of home based vital monitoring devices in which approved for medical use [5], however we are providing the platform in which we can provide better services upon the data from these devices, as per Fig. 9. Typical specialized devices are pulse-oximeters ,blood-pressure, hart-rate, and blood-sugar monitors. Once the e-Health data collected, it become available to specialists, where they can start provide help to patients by providing instruction and first-aid technique upon patient condition (using SHES communication feature) until paramedic arrival.

Fig. 9

SHES e-Health Monitors

6 Conclusion and future work

The modern population structure has changed vastly due to the increasing aging population within the UK. With an increase in population, and larger numbers of elderly people living to older ages, whom are also known to utilise an increased amount of emergency resources, the emergency services response protocols are sure to be under additional strain within the near future. This is already apparent through the large number of increased unanswered calls, resulting in many deaths a year. Even with answered and responded calls, deaths are still occurring through the increased ambulance response times. Therefore, this paper propose the Smart Hospital Emergency System (SHES) the needs of the current emergency response procedures by a new approach for emergency response requests by the public. SHES aims at enhancing the emergency services by making justified changes of implementations and procedures of current emergency response protocols to attempt to solve the issues stated throughout the research of this work. We have illustrated that it is possible to exploit the use of increasingly common built-in technologies within mobile smartphones to help aid emergency services in their roles by increasing efficiency through already commonplace technologies. The system has been evaluated by a preliminary usability, reliability, and communication performance study.

Although the development of the SHES prototype and the features within have been carried out successfully, we have identified a number of features that could be incorporated into our system at a later date. These features would improve the system through iterative design. For example, such as multi-language support to broaden the use of the system, in addition, an indoor location tracker could be essential for locating the patient if visual or audio communications between patient and emergency services are cut. As mentioned previously, it is important that SHES is accessible to as many potential users as possible regardless of their smart-phone OS. As technologies become more widespread and cost effective, especially as we are entering the era of Internet of Things (IoT), it is highly likely that we will continue to see the increased use of IoT devices within the healthcare health sector. Overall, this system leaves a lot of room for future development, opportunities, and further research as more researcher becomes interested in the crossover fields of ICT and healthcare.