Why is ems in a unique position to contribute significantly to mobile integrated health care?

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.

The general necessary requirements of an EMS are separated as functional and nonfunctional as listed, in a nonexhaustive way, in the following link: https://bit.ly/3tQOj1g. eEKAB was developed to meet most of these requirements. As mentioned before, it was designed to help the coordination and cooperation between the EKAB departments and more specifically the ambulance crew and the doctors. The goal of its design was to optimize the emergency care services by automating procedures and reducing the time of prehospital care procedures. For the application design, the client–server architecture was adapted to the mobile environment of the prehospital procedure [24]. eEKAB consists of a web server, connected to a database and a multitude of mobile clients who connect to the server and interact with the database. eEKAB consists of two separate modules, one designed to run on the web server and the other designed to run on the mobile clients. The application server is handled by the controllers while the mobile application is handled by the crew of the ambulances and the physicians who play the role of mobile clients. The mobile clients are mobile phones that the doctors and the ambulance crew must connect to the web server and interact with the database. Both applications use two agents, one on the server side and one on the client side so that the communication follows the scheme client–agent–agent–server and vice versa. These agents handle the communication between the server and the clients asynchronously. Thus, the control center is not delayed by the required connection between client and server as it is asynchronous. In addition, it is possible to adopt a publish–subscribe model for the services used. The scenario followed by eEKAB is described in Figure 1.

When an emergency call reaches the eEKAB call center, the person at the help desk starts recording the patient's details. Then, he selects the nearest available doctor and ambulance from the list of clients. The ambulance crew and the doctors receive a notification on their mobile devices that an incident is in progress. When they open the notification, the incident location and instructions on how to arrive are automatically displayed on their mobile screen. In parallel, with the help of agents, the database is updated that this ambulance/doctor took over the incident. Finally, when the ambulance/doctor successfully offers its services in the incident, he closes the notification and informs the corresponding database.

The mobile applications were developed using the Google Android operating system. This system provides seamless support for network communication, through socket programming and WiFi and allows its integration with maps using the Google Map API and a GPS sensor. eEKAB leverages on these and other built-in sensors to update the relevant databases.

The Google Map API is used to implement the process of presenting a map to clients showing their location and the shortest route to their destination. Through this API, the control center can visualize location maps of the ambulances, the doctors and the incident. Thanks to the Google web service, the distances and the estimated time of an ambulance or a doctor can be calculated, so that the closest to the incident people can be identified.

The application server for the operations center was implemented using PHP (Hypertext Preprocessor). The application launch triggers another program that plays the agent role and takes over the part of communicating with the client through sockets. The REST architectural style was used to distribute the communication overhead between the operations center and the ambulance application. Each REST API establishes a loosely coupled communication between the client and the server via HTTP and enables the servers to cache the response. As a result, they improve the performance of the application. Multiple types of new clients can be also introduced without considering the backend implementation. The available clients communicate with the backend endpoints as shown in Figure 2.

jQuery, a JavaScript library for easier HTML development, was used for checking the events (e.g. the actions that follow when a button is pressed), for checking all forms for incorrect insertions and for presenting the original application records and dialog boxes as well as the forms for importing/modifying ambulances and doctors.

In addition, Ajax helped us to perform some operations asynchronously. Specifically, Ajax is used in the field of the incident address to display a list of possible addresses (which are valid Google map addresses), depending on the typed address to ensure its validity. Moreover, the list of available ambulances and doctors is provided asynchronously when requesting the form with the incident details.

Hereafter, some operations that contribute to the user experience are briefly presented. By selecting in the mobile application, the function, named “Emergencies”, the recording of the medical incidents is performed. To the left of the application home page, the incidence entry form is depicted, while to the right, a map (naturally derived from Google Maps) showing the incident, the available doctors and the available ambulances. As soon as the user enters the correct values in all fields and presses the “Submit” button, the incident is automatically inserted into the database and a new area appears at the bottom of this page, called “Doctors and Vehicle Search”. The map demonstrates all the available doctors and all the currently available ambulances. The incident appears in red and with the letter I (Incident), the doctors in blue and with the letter D (Doctor) and the ambulances in green and with the letter A (Ambulance). At https://bit.ly/3uDnGxa, a demonstration part of the “Doctors and Ambulances Search” area after reporting the incident and the nearest route to reach it is depicted. In companion of that, lists for ambulances and for doctors are available to the staff so that they are aware of the details of all the involved entities.

The user authentication on the mobile application is achieved by filling the phone number and the given secret code for the mobile phone owner. The client receives a popup message to confirm whether the authentication was successful. Once the login form is completed, a warning message that automatically closes in 20 seconds is displaced indicating the username and informing him about four things:

1. The mobile was connected to the central server application.

2. The application will periodically send the location of the mobile to the central eEKAB application, informing the central server database.

3. The application is now running in the background, waiting to receive an incident.

4. If an incident is received, then, a notification is displayed on the mobile phone.

In case an incident is sent to the ambulance, a new notification on the respective mobile phone informs the crew that a new incident has arrived. As soon as the alert is opened, a Google map shows the current position of the ambulance (blue dot) and the route to the incident (Figure 3).

The criteria-driven approach that uses evaluation criteria was used in this work [25, 26]. The focus of this approach is on setting specific properties that are important for the evaluation of the information systems. The evaluation is based on defined criteria without user intervention as there were no users available to contribute to the evaluation. The criteria are divided into categories with specific category and criteria weights. The following formula is used [25]:where wj is the category weight j, sji is the value of criterion i of category j, wji is the weight of i of category j, n is the number of categories and kj is the number of evaluation criteria of category j. Q provides an appropriate assessment metric of the quality performance of EMS. It reveals to what degree the fulfillment of the set requirements is achieved. Indicative evaluation criteria with their respective weights and criteria value are presented in Table 2.

Due to space limitations, a short example is provided, which provides details of the second evaluation criterion of Table 2, namely the cost. The cost of eEKAB is derived from the web server cost, the cost of the android mobile devices, the cost of the professional Google Maps service and the network cost. The web server cost will range from 2,000 to 5,000 euros. We also need around 1,200 mobile android phones (based on the number of EKAB vehicles). Assuming the cost of a mobile android is 75 euros, their total cost is about 75 × 1200 = 90,000 euros. For their interconnection, a mobile VPN (virtual private network) is used, which provides the greatest possible reliability and security and costs about 88,800 euros a year. The Google Map service costs 8,000 euros per year. The prices are indicative, but the cost is approximately 100,000 euros for the original equipment plus approximately 100,000 euros per year for the provided services. These costs are by no means prohibitive for a public service such as EKAB. On this criterion, a weight value of 3 is given, as it is considered a very important part of the EMS and criterion value 3 as we consider that the cost for upgrading a very critical public service is quite low. Next, the total application effectiveness Q was calculated as follows:

We observe that the system performance is 130. That on its own is not enough to provide a sense of the performance of the information system. For this reason, its performance is compared with the performance of four other systems. The first system that does not fully meet the initial requirements applies the yield Q = 52 (expressing the current EKAB system). The second system fulfills the requirements and has a yield of Q = 104. The third slightly exceeds the requirements and gives a Q = 156 and, finally, the fourth system substantially fulfills the requirements with a Q = 208. We observer that eEKAB has a Q value between the second system that meets the requirements and the third that slightly exceeds them. Furthermore, if we assume that the perfect system has Q = 208 then, our system has a 62.5% efficiency on a scale of 100, which means that further system usage and processes improvements must be enforced.

On the other hand, the proposed system compared to the current system of EKAB is more efficient. Indeed, eEKAB improves the current system of prehospital medical care in computerization of incident data with the ability to analyze them and draw conclusions, in reduction of EKAB procedures time, in more efficient management of the EKAB system, in better distribution of human resources, in better geographical distribution of ambulances/doctors after case analysis and in visualization of ambulance/doctors map and route to the incident. The high-level estimation in the performance for the eEKAB system is obvious since both the ambulance matching and the map navigation steps have been fully automated. Figure 4 depicts the differences before and after the adoption of automated EMS services toward the direction to reduce both the time and the cost.

The evaluation of the functional requirements was applied through a survey, using the quantitative research method. The aim was to determine whether the users of the eEKAB identify any advantages or useful features. The research was conducted online via simulation on 100 ambulance drivers who evaluated the importance of the application when an emergency incident call was available. The ambulance drivers downloaded the application to their mobile phones, created their free account and used it in terms of providing emergency prehospital care to the patients. The ambulance drivers received a notification via the eEKAB application and observed on the map if the ambulance crew could arrive in the incident's location on time. After having used the application at least once, they had to complete a questionnaire to express their satisfaction or displeasure, regarding the application. The survey data are provided in the following link: https://bit.ly/32KDJgu.

The analysis of the research demonstrates that there were 74 drivers under 40 years old and 26 above 41 years old. We used SPSS to process and analyze the survey data. The chi-square statistic test was applied to investigate whether the effectiveness of the eEKAB application is correlated with the age difference of the ambulance drivers. The statistic test (X2 = 100, p = .00) proved that 74% of the ambulance drivers who are under 40 years old expressed their satisfaction about the essential and vital contribution of the application to the provision of emergency health care to the patients. It seems that the younger ambulance drivers tend to find the eEKAB more effective. The survey analysis is provided in the following link: https://bit.ly/2Pk7x0h.

The bivariate statistic test was used to calculate the Pearson correlation coefficient to investigate the existence of a statistically significant relationship between the effectiveness of the notification for the incident's location with the responder's perception on recommending the eEKAB application to other ambulance drivers and having a friendly user experience for accessing useful information via the mobile phone. The analysis showed that there is a perfectly positive linear relationship (r = 1, p = 0.00) between the immediate sending of the emergency notification and the positive perception from responders on adopting the eEKAB beyond pilot mode. Also, a perfectly positive linear relationship (r = 1, p = 0.00) emerged between the speed of sending the alert and the increased probability of recommending the application to new ambulance drivers. Finally, there was a perfectly positive linear relationship (r = 1, p = 0.00) between taking into account immediately the alert without delay and easily finding the route to quickly pick up the patient from the location indicated by the application. The results highlight the fact that receiving the notification on time significantly helps the ambulance drivers to properly transport the patients to the hospital. Thus, they consider the application efficient enough, and they want to recommend it to other colleagues and promote it beyond its pilot test phase. The Pearson metrics are provided in the following link: https://bit.ly/3dNSbKT.