An Approach to Build e-Health IoT Reactive Multi-Services Based on Technologies around Cloud Computing for Elderly Care in Smart City Homes^†

Round 1

Reviewer 1 Report

The article is well written and organized, and the conclusions are supported by presented results. It provides a signficant extension of the previous work published by the authors in a conference. I have only some minor comments/suggestions: 

    - Figure 1 -> "DDD" appears in two lines. 
   - Figure 5 -> Resolution needs to be improved for reading forms. 
   - Subsection 5.2. Typo, "La Figure" should be "Figure".
  - Subsection 5.3. Reference 44 corresponds to MongoDB, while no reference is provided for MySQL. Please, add a reference for MySQL and modify references accordingly.

Author Response

 

Response to Reviewer 1

 

Dear Editor Dr. Jung,

 

We appreciate you and the reviewers for your precious time in reviewing our paper and providing valuable comments. It was your valuable and insightful comments that led to possible improvements in the current version. The authors have carefully considered the comments and tried our best to address every one of them. We hope the manuscript after careful revisions meet your high standards. The authors welcome further constructive comments if any.

Below we provide the point-by-point responses. All modifications in the manuscript have been marked using the "Track Changes" function in Microsoft Word.

 

Luis Jurado Pérez

PhD Student

Departamento de Ingeniería de Sistemas Telemáticos

Universidad Politécnica de Madrid (UPM)

Avenida Complutense, 30, 28040 Madrid

luisalberto.jurado.perez@alumnos.upm.es, luisjuradoperez@yahoo.com

Tel: ++3-460-336-1644

 

General Comments:

“The article is well written and organized, and the conclusions are supported by presented results. It provides a significant extension of the previous work published by the authors in a conference.”

Response: Thank you for your comments. We have gone through your comments carefully and tried our best to address them one by one. We hope the manuscript has been improved accordingly.

[Specific Comments (1)]: “I have only some minor comments/suggestions:”

- Figure 1 -> "DDD" appears in two lines. 

- Figure 5 -> Resolution needs to be improved for reading forms. 

- Subsection 5.2. Typo, "La Figure" should be "Figure".

- Subsection 5.3. Reference 44 corresponds to MongoDB, while no reference is provided for MySQL. Please, add a reference for MySQL and modify references accordingly.

Response: Thank you very much for the comment. We did our best to correct these mistakes.

 

 

Line 117:  Figure 1 was corrected, DDD has been left on a single line.

Line 545:  Figure 5 has been reorganized so that the indicated graphical user interfaces can be visualized in a better way. In addition, the resolution of the figures was improved.

Line 676:  In Subsection 5.2, "The Figure" was changed to "Figure".

Line 697:  In Subsection 5.3, a reference for MySQL was added. Additionally, the references were renumbered due to the addition of this new reference. 

Author Response File: Author Response.pdf

Reviewer 2 Report

The manuscript describes an approach to solve an emerging challenge about the healthcare of elderly people. The separation between the software development (and technology) and health services is projected to be a bottleneck by 2050. There must be an approach that address this difference holistically, such that e-health services will be concurrent with technology, scalable, accurate, and private.

The authors presented excellent motivation and background details about the challenge in the manuscript and presented their approach architecture and implementation. Furthermore, the author presented their results and analysis that are based on the implementation.  

Overall, the idea and proposed approach is interesting and motivated by urgent need for such a holistic approach to mitigate challenges that face elderly care. The technical details and analysis are sufficient to present the authors’ case. The technical content spanned over several layers of the approach (design to implementation). However, there are some shortcomings that reduce the novelty of the proposed approach.

• One of the major concerns with is approach is data privacy and security. The authors mentioned anonymization to prevent private information and discussed MongoDB to provide security mechanism. However, there are other factors that affect these decisions. For instance, how can this approach be compatible with HIPPA? Who (medical providers, food stores, housekeeper, etc.) has access to which information (health, diet, etc.)? How does crowdsourcing factor into data privacy?
• The results showed the feasibility of the proposed approach. However, it is not clear whether the discussion is focusing on the quantitative technical results (e.g., latency, throughput, number of requests, etc.), or e-health services validity of the approach. The authors could investigate the possible challenges implementing such approach, in light of logistics and privacy. Discussing both areas could be a little confusing to the reader.
• Is there a reason why there are only two scenarios, basic service managements and management of diets?
• What dole does machine learning play in the database? What are these models?
• There is much detail that describes the technical components—all 5.x items, JSON explanations, etc., which paint the manuscript with a technical report color rather than an applied science manuscript. Furthermore, the technical details are supportive of the authors competent in the subject, but could be shortened so that the manuscript focuses on the underlying challenge being solve (e-health services)
• The dynamics of the emergency service (6.4) are not clear. The simulated information is sent to the patient’s phone -> EMQ -> apache, and concurrently to the health professional’s phone?
• Section 6 could be shortened to be more concise and focused on e-health services discussion.

Author Response

 

 

 

Response to Reviewer 2

 

Dear Editor Dr. Jung,

 

We appreciate you and the reviewers for your precious time in reviewing our paper and providing valuable comments. It was your valuable and insightful comments that led to possible improvements in the current version. The authors have carefully considered the comments and tried our best to address every one of them. We hope the manuscript after careful revisions meet your high standards. The authors welcome further constructive comments if any.

Below we provide the point-by-point responses. All modifications in the manuscript have been marked using the "Track Changes" function in Microsoft Word.

 

Luis Jurado Pérez

PhD Student

Departamento de Ingeniería de Sistemas Telemáticos

Universidad Politécnica de Madrid (UPM)

Avenida Complutense, 30, 28040 Madrid

luisalberto.jurado.perez@alumnos.upm.es, luisjuradoperez@yahoo.com

Tel: ++3-460-336-1644

 

General Comments:

The manuscript describes an approach to solve an emerging challenge about the healthcare of elderly people. The separation between the software development (and technology) and health services is projected to be a bottleneck by 2050. There must be an approach that address this difference holistically, such that e-health services will be concurrent with technology, scalable, accurate, and private.

The authors presented excellent motivation and background details about the challenge in the manuscript and presented their approach architecture and implementation. Furthermore, the author presented their results and analysis that are based on the implementation.

Overall, the idea and proposed approach is interesting and motivated by urgent need for such a holistic approach to mitigate challenges that face elderly care. The technical details and analysis are sufficient to present the authors’ case. The technical content spanned over several layers of the approach (design to implementation). However, there are some shortcomings that reduce the novelty of the proposed approach.

Response: Thank you for your comments. We have gone through your comments carefully and tried our best to address them one by one. We hope the manuscript has been improved accordingly.

[Specific Comments (1)]: One of the major concerns with is approach is data privacy and security. The authors mentioned anonymization to prevent private information and discussed MongoDB to provide security mechanism. However, there are other factors that affect these decisions. For instance, how can this approach be compatible with HIPPA? Who (medical providers, food stores, housekeeper, etc.) has access to which information (health, diet, etc.)? How does crowdsourcing factor into data privacy?

Response: Thanks for your kind reminders.

Due to the objectives of our research, we have indicated a reduced set of security mechanisms for the system. We hope that our approach helps to take into consideration the need to mitigate security risks as well as show the importance of adapting to the security requirements within the Internet of Things domain and the use of security services of platforms of Cloud Computing. A comprehensive and extended study of system security and including privacy is a broad line of research and is beyond the scope of our article.

 

We have made some changes to the article to delimit the research:

 

1. We have added lines 865-886 to delimit the research:

 

“The information security of the services discussed in this paper is a critical issue that must be considered for data at movement or at rest. Although we have pointed out some security mechanisms, a full study of security mechanisms is beyond the scope of this article. Some challenges that must be addressed to increase the security of the data of e-Health systems are indicated below.”

“The collection of sensitive medical data from homes poses complex security and privacy challenges due to the open nature of patient data that is susceptible to eavesdrop. In [64], some issues related to privacy and security of WBANs are mentioned, such as accountability, which is related to the need for a person who possesses patient information to have the responsibility to safeguard such information.”

“Moreover, there are several concerns about the data collected by crowdsensing applications since users' personal devices could be connected to insecure access points or be contaminated with malicious code, which opens up several challenges regarding detecting the veracity of the data collected [65]. On the other hand, in many countries, the treatment of medical data must follow strict medical regulations, such as the Health Insurance Portability and Accountability Act (HIPAA) in the United States. In recent years, there has been great interest from cloud computing platform providers such as Google and Amazon in offering HIPAA compliant services for hosting sensitive data [66] [67]. However, the implementation of HIPAA compliant systems that, for example, support a failure in the infrastructure of the cloud platform, together with the lack of control by the owners over these infrastructures, or the lack of direct interpretation of the property of the data and the use of this information are some of the challenges that still have to be faced [68].”

 

2. The following references were added and the current references were renumbered:

 

[64] Selvaraj, P.; Doraikannan, S. Privacy and Security Issues on Wireless Body Area and IoT for Remote Healthcare Monitoring. In Book Intell. Pervasive Comput. Syst. Smarter Healthc; A.K. Sangaiah, S. Shantharajah and P. Theagarajan; 2019; pp. 227–253.

[65] Li Y., Jeong Y., Shin B. and Park J. H. Crowdsensing Multimedia Data: Security and Privacy Issues. IEEE MultiMedia. 2017, 24, 4, 58-66, doi:10.1109/MMUL.2017.4031306.

[66] Google Cloud – Compliance | HIPAA. Available online: https://cloud.google.com/security/compliance/hipaa-compliance (accessed on 30 March 2021).

[67] HIPAA Compliance - Amazon Web Services (AWS). Available online: https://aws.amazon.com/compliance/hipaa-compliance/ (accessed on 30 March 2021).

[68] Al-Marsy, A.; Chaudhary, P.; Rodger, J.A. A Model for Examining Challenges and Opportunities in Use of Cloud Computing for Health Information Systems. Appl. Syst. Innov. 2021, 4, 1, 15, doi:10.3390/asi4010015

 

• [Specific Comments (2)]: The results showed the feasibility of the proposed approach. However, it is not clear whether the discussion is focusing on the quantitative technical results (e.g., latency, throughput, number of requests, etc.), or e-health services validity of the approach. The authors could investigate the possible challenges implementing such approach, in light of logistics and privacy. Discussing both areas could be a little confusing to the reader.

Response: Thanks for the comment.

In our research, we have used some of the techniques suggested by the iterative process of architectural design by Rozanski and Woods (Section 3.1). One of these techniques is the use of scenarios that we have used to define and validate the scope of the system. Other techniques used are the implementation of the prototype and proofs-of-concept which were used to study some technical requirements under investigation. One of the requirements is the scalability of the system, so it was necessary to configure a simulation environment to validate this requirement and study the performance.

 

Thus, due to the objectives of our research and the limits established in the scope and context of the use case scenarios, we have established a set of requirements that were used to establish solutions through our approach including the challenges to face (Section 4.1.3).

 

A study of all the challenges and possible solutions to tackle other possible requirements for an improvement of current services or other new types of services is a broad line of research and is beyond the scope of our article.

 

 

We have added lines 418-422 to delimit the research:

 

“One of the techniques suggested by the iterative process of architectural design by Rozanski and Woods [27] is the use of scenarios which was used for the establishment of requirements, the definition, and validation of the scope of the system. These requirements were used for the development of the architecture description, the construction of a prototype, and the proofs of concept.”

 

• [Specific Comments (3)]: Is there a reason why there are only two scenarios, basic service managements and management of diets?

Response: Thanks for your kind reminders. We have made revisions accordingly.

 

We have limited our investigation to two scenarios due to time constraints. We are encouraged to use our approach to introduce new applications and services and to investigate new techniques, methods, or algorithms around additional health services. In Figure 3, we have indicated the possibility that the architecture supports multiple services in its application layer (Specialized Web Apps).

In the conclusions, we have also indicated other possible services where we wish to work in the future: sleep care services, medication intake care services, and cognitive function care services.

 

We have added lines 422-425 to delimit the research:

 

 “In order to show the possibility of building multiple applications and services, and restricted by time, only two scenarios are presented that were used for the elaboration of the architecture description. However, additional applications and services in the health field could be conceived and built through our approach.”

 

• [Specific Comments (4)]:  What dole does machine learning play in the database? What are these models?

Response: Thank you very much for nice reminder. We did our best to improve the article.

Applications that use machine learning are outside the limits of this paper.

In general, machine learning models could be obtained through the processing of existing data in the database through specialized algorithms. These models are logical structures stored in files that can be used by other applications that require such models. These applications could be deployed as new services together with the models in a container.

In our work, we incorporate a basic configuration of a subsystem of big data for the treatment of the data collected by the IoT system, which extends the possibility of creating services related to data analytics in batch and real-time modes.

We have moderated some expressions in several lines of the text of the paper where we make references to the use of machine learning.

 

1. Section 5.7.3 was modified:

We have removed lines 780-782:

"On the other hand, other applications such as those that use Machine Learning can use this package for data processing and obtaining predictive models."

 

2. Section 5.7.4 was modified:

We have removed lines 787-789:

"This connector could be incorporated into the data analytics applications for batch processing and thus summarize data or obtain Machine Learning models."

 

We have added lines 789-791:

“Additionally, other applications can be conceived, such as those that could use this connector together with the connector of Section 5.7.3 to process data in batch mode and obtain Machine Learning models.”

 

• [Specific Comments (5)]:   There is much detail that describes the technical components—all 5.x items, JSON explanations, etc., which paint the manuscript with a technical report color rather than an applied science manuscript. Furthermore, the technical details are supportive of the authors competent in the subject, but could be shortened so that the manuscript focuses on the underlying challenge being solve (e-health services)

Response: Thanks for your kind reminders. We have made revisions accordingly.

An in-depth description of some technicalities of the system sometimes has pros and cons. For this reason, most of the technical material is in the appendices. In this way, we have tried to balance the information of the main article and the appendices so that the article can be read by a greater number of subscribers to the Journal Applied Science. We have proceeded in this way because we believe that the findings presented in our article will appeal not only to healthcare automation managers but also to members of developer teams and other professionals who subscribe to the Journal Applied Sciences.

 

Since some technical details can be found in the references, we have proceeded to abbreviate some of them to alleviate the reviewer's concerns.

 

1) Section 5.1 was modified:

 

We have removed lines 653-655:

“Google Cloud Platform provides typical cloud services such as IaaS, PaaS, and SaaS on a range of components such as Google Compute Engine (GCE), Google Kubernetes Engine (GKE), Google App Engine (GAE), and Google Cloud Functions [41] "

 

We have abbreviated the lines 659-660:

 “Following the deployment view, the system's preproduction environment was implemented with a K8s cluster version 1.12 which we have called eHealth-System-K8s cluster. "

 

We have removed lines 661-663:

"The eHealth-System-K8s cluster was divided into two node pools: eHealth-System-K8s-cluster nodepool-1 and eHealth-System-K8s-cluster nodepool-2."

 

2) Section 5.2 was modified:

 

We have abbreviated the lines 671-674:

“Play Framework is an MVC framework and is based on a lightweight, stateless, web-friendly architecture for highly-scalable reactive applications.”

 

We have removed lines 673-674:

“Play Framework is built on top of Netty and uses asynchronous stream handling provided by reactive streams.”

 

3) Section 5.3 was modified:

 

We have removed lines 701-704:

“Due to the objectives of this work, a MongoDB replica set was used as it offers less latency than a sharded cluster. Thus, the MongoDB cluster was installed using instances of MongoDB, one instance as a primary node, and two additional instances as secondary nodes.”

 

4) Section 5.4 was modified:

 

We have abbreviated the lines 707-708:

“In this work, a cluster of EMQ brokers was used.“

 

We have removed lines 710-711:

“Additionally, a cluster architecture of EMQ brokers is based on distributed Erlang / OTP and Mnesia database.”

 

We have removed lines 713-716:

“For the implementation of the architecture, we deployed an the EMQ cluster with three nodes on the eHealth-System-K8s-cluster nodepool-2. The deployment was carried out through properly configured YAML files to download the images from Docker Hub and to install the external load balancer that exposes the cluster services.”

 

We have added the lines 717-719 that abbreviate the deleted lines 713-716:

“For the architecture implementation, we deployed the EMQ cluster with three nodes in eHealth-System-K8s-cluster nodepool-2 (see Section 4.2.5) with images from Docker Hub.”

 

5) Section 5.5 was modified:

 

We have removed lines 723-730:

“IoT systems with capabilities to provide services to a large population group in a city need to incorporate in their architectures a message broker with high scalability as a primary element in their communications channel. In this paper, the first message broker used in the channel is the EMQ broker. EMQ broker is capable of collecting data from devices with reduced capacities but provides medium scalability to handle messages (millions of messages). “

“Due to the reduced capabilities of the EMQ broker, an additional platform called Confluent was incorporated into the system architecture”

 

We have added the lines 730-734 that abbreviate the deleted lines 723-730:

“For the system to offer services to a large population group in a city, it is necessary to incorporate a high-capacity messaging communication channel into its architecture. Due to the medium scalability of the EMQ (millions of messages), the Confluent platform has been incorporated into the communications channel [47].”

 

6) Section 5.6 was modified:

 

We have removed lines 742-748:

“The characteristics of Apache Spark, such as streaming processing, machine learning libraries, fast, SQL language, and using in-memory distributed computing together, satisfy the requirements of the system. In the prototype, Apache Spark v2.4 was used as a cluster computing system to enable batch processing of data from MongoDB or to enable near-real-time processing of data from messaging brokers. The main objective of the system to use Apache Spark was the implementation of the alert manager to meet the requirements indicated in Section 4.2.2.”

 

We have added the lines 748-753 that abbreviate the deleted lines 742-748:

“The characteristics of Apache Spark v2.4, such as streaming processing, fast, SQL language, and using in-memory distributed computing together, satisfy the requirements of the system. Although Apache Spark allows data processing in batch mode and near real-time processing, in the prototype an Apache Spark cluster was only used as the near real-time processing component to support the Alert Manager (Section 4.2.2).”

 

We have removed lines 758-760:

“This application is managed by Apache Spark that controls the execution of a Spark driver that sets the execution context and the Spark executors as instances of the Spark application”

 

• [Specific Comments (6)]: The dynamics of the emergency service (6.4) are not clear. The simulated information is sent to the patient’s phone -> EMQ -> apache, and concurrently to the health professional’s phone?

 

Response:  Thank you very much for the comment. We did our best to correct these mistakes.

 

In our prototype of the system, we have considered that there is a Mobile App (an MQTT client) on the health professional's phone and that it is capable of receiving only emergency messages. The descriptions of the dynamics of the emergency service and Figure 20 were improved to improve the understanding of the service.

 

The dynamics of the emergency service was reduced by 6 points and modified to clarify the concerns of the reviewer: Lines 1258 - 1290

 

Figure 20 was modified to highlight the system components that generate the messages with the topic "emergencyTopic": Line 1313

 

 

• [Specific Comments (7)]:  Section 6 could be shortened to be more concise and focused on e-health services discussion.

Response: Thanks for the comment.

We've made a few changes to make Section 6 shorter and ease the reviewer's concerns:

 

• Section 6 was modified:

 

We have removed lines 898-904 since the simulation scenarios are explained in each of the experiments:

 

“The scenarios of the experiments were prepared for the preproduction test environment and were configured on K8s Clusters: eHealth-System-K8s cluster and JMeter-K8s cluster. The eHealth-System-K8s cluster was used to deploy the entire e-health system, and the JMeter-K8s cluster was used to deploy Apache JMeter in a distributed testing mode. In this way, we were able to isolate the JMeter-K8s cluster and did not influence the tests of the system components. The JMeter-K8s cluster consisted of four nodes to deploy one JMeter master and three JMeter slaves.”

 

We have added lines 904-907 which abbreviates lines 898-904:

 

“The scenarios of the experiments were prepared for the preproduction test environment and were configured on K8s Clusters: eHealth-System-K8s cluster (entire e-health system) and JMeter-K8s cluster (Apache JMeter in a distributed testing mode).”

 

2) Section 6.1 was modified:

 

We have moved the content of lines 945-953 to an additional appendix (Appendix G).

 

Table 3 was moved to Appendice G, so we also renumber the tables of the paper according to this change: Lines 955-957

 

We have added lines 942-943:

"For additional details on the JSON message structure of the patient's vital signs data, see Appendix G."

 

3) Section 6.2 was modified:

 

We have moved the content of lines 1003-1009 to an additional appendix (Appendix H).

 

Table 4 was moved to Appendice H, so we also renumber the tables of the paper according to this change: Lines 1028-1029

 

We have added lines 1009-1010:

"An example of the data size of the input and output of each operation can be found in Appendix H."

 

We have removed the lines 979-989:

 

“The objective of these experiments was to analyze the performance and scaling of core services and specialized services through various workload tests. In general, these services are based on microservices and receive requests from users' devices to perform operations on the database tables. A small group of microservices with typical operations on the database were used for the execution of the tests. We experimented with individual microservices that manage the elderly people table in the MongoDB database. These microservices use common operations on the elderly people table, which are the operation of saving a document, the individual or group reading of documents, the updating of a document, and the deletion of a document. Typical access to microservices was implemented through a K8s Ingress Controller. This K8s Ingress provides flexible access to different microservices through a single IP address.”

 

We have added the lines 989-995 that abbreviate the deleted lines 979-989:

 

“The objective of these experiments was to analyze the performance and scalability of core services and specialized services through various workload tests. For this, we experimented with individual microservices that manage the elderly people table in the MongoDB database through the following operations: saving a document, the individual or group reading of documents, the updating of a document, and the deletion of a document. Flexible access to microservices was implemented through a single IP address of a K8s Ingress Controller.”

Author Response File: Author Response.pdf

Reviewer 3 Report

This paper designs system for a health Internet of Things (IoT) development and deployment. It targets on the e-health IoT reactive multi-services. 
The proposed architecture incorporates a big data subsystem for data analytics in batch and near-real-time modes. The experimental results demonstrate its scalability and extensibility. While the paper focuses on an important field and conducts intensive experiments on a testbed, the system does not consider the network delay in the wireless environment and the lack of computing resources on IoT devices. This kind of system involves a cloud-edge-end two-tier system to enhance accessibility and provide reliable services. 

Author Response

 

Response to Reviewer 3

 

Dear Editor Dr. Jung,

 

We appreciate you and the reviewers for your precious time in reviewing our paper and providing valuable comments. It was your valuable and insightful comments that led to possible improvements in the current version. The authors have carefully considered the comments and tried our best to address every one of them. We hope the manuscript after careful revisions meet your high standards. The authors welcome further constructive comments if any.

Below we provide the point-by-point responses. All modifications in the manuscript have been marked using the "Track Changes" function in Microsoft Word.

 

Luis Jurado Pérez

PhD Student

Departamento de Ingeniería de Sistemas Telemáticos

Universidad Politécnica de Madrid (UPM)

Avenida Complutense, 30, 28040 Madrid

luisalberto.jurado.perez@alumnos.upm.es, luisjuradoperez@yahoo.com

Tel: ++3-460-336-1644

 

General Comments: This paper designs system for a health Internet of Things (IoT) development and deployment. It targets on the e-health IoT reactive multi-services. 
The proposed architecture incorporates a big data subsystem for data analytics in batch and near-real-time modes. The experimental results demonstrate its scalability and extensibility.

Response: Thank you for your comments. We have gone through your comments carefully and tried our best to address them one by one. We hope the manuscript has been improved accordingly.

[Specific Comments (1)]: While the paper focuses on an important field and conducts intensive experiments on a testbed, the system does not consider the network delay in the wireless environment and the lack of computing resources on IoT devices.

Response: Thanks for your kind reminders.

The exact simulation of patient behavior and the wireless body area network (WBAN) is outside the limits of our work. Due to some works that show technological advances in medical sensors, microelectronics and low-power miniaturization, communications and wireless networks, we have considered possible the real-time detection of vital signs [RR-1] [RR-2].

 

[RR-1] Felisberto, F.; Costa, N.; Fdez-Riverola, F.; Pereira, A. Unobstructive Body Area Networks (BAN) for Efficient Movement Monitoring. Sensors 2012, 12, 12473-12488. https://doi.org/10.3390/s120912473

 

[RR-2] M. Hu and Y. Wang, "Design of Wearable Wireless Body Area Network Monitoring System," 2020 IEEE 3rd International Conference on Information Systems and Computer Aided Education (ICISCAE), 2020, pp. 585-588, doi: 10.1109/ICISCAE51034.2020.9236924.

 

In addition, since we have worked with a reduced number of vital signs, we have considered that this represents a reduced number of nodes in a WBAN and therefore less congestion.

 

In our experiments, we have simulated a sampling time of 1 second. An additional process for data integration is taking into account which is also processed by the simulator. Additionally, the process of sending the data is carried out from the MAC to a real smartphone through a real Bluetooth connection.

 

Figure 21.a shows the moment in which the vital signs are sampled: 20: 41: 55.607

Figure 21.b shows the moment in which the data reaches the patient's smartphone (PacientMobileTime): 20.41: 57.169. This data is shown here because once the sampling data reaches the patient's smartphone, it is encapsulated in a new structure that includes the timestamp of arrival at the patient's smartphone. This new structure (emergencyState) is sent to the paramedic's smartphone (in case of emergency).

The approximate value of the time required to transfer the sampled data to the patient's smartphone is the difference between the values indicated above: 1,562 seconds.

 

On the other hand, due to the objectives of our research and the requirements established in the scope and context of the use cases, the study of the effects of the lack of computing resources on IoT devices are outside the limits of this paper. We have made some changes to the article to delimit our research and show the need to establish certain considerations for these open research issues:

 

We have added lines 969-976 to delimit the research:

 

“It is necessary to point out that a more exact simulation of the behavior of the patient and the WBAN is outside the limits of our work. Therefore, we have modeled the simulator considering only the sampling stages, integration of the sampled data and the sending of the detected data from the MAC to the patient's smartphone. Despite the technological advances in medical sensors, microelectronics and low-power miniaturization and communications, there are some open issues around a WBAN that must be taken into consideration when designing and building this type of network. One of these challenges to face is the limitation of memory, processing and power in the nodes of a WBAN [76].”

 

We have added the following reference to the article and the current references were renumbered:

 

[76] Majumder, S.; Mondal, T.; Deen, M.J. Wearable Sensors for Remote Health Monitoring. Sensors 2017, 17, 130. https://doi.org/10.3390/s17010130.

 

[Specific Comments (2)]:  This kind of system involves a cloud-edge-end two-tier system to enhance accessibility and provide reliable services. 

Response: Thanks for the comment.

In our research, we consider the smartphone as an edge device that provides intelligence, processing, and communication capabilities. We have supported the system architecture with fast data components to alleviate latency problems between the interaction of the edge device and the cloud computing platform. Our cloud computing provider (Google) has several data centers in certain parts of the planet. To deploy the architecture, we have chosen the closest data center (London) to our research point (the city of Madrid). This also helps the streaming platform data analysis and ingest processes. Our approach can help conceive IoT applications that can extract value from data in motion and data at rest.

 

 

 

 

Author Response File: Author Response.pdf