Fog Computing and Graph-Based Databases for Remote Health Monitoring in IoMT Settings

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

The study proposes a four-layer IoMT–Fog–Cloud architecture utilizing Neo4j graph databases in Fog nodes for scalable remote patient monitoring, demonstrating its efficiency in processing high volumes of health data with low latency under various simulated scenarios.

authors introduce a Fog layer for data processing and exchange, but all the tests ran on local laptop; a better way is to set up some real IoT devices e.g., raspberry pi to send data, via Gateway device or cell phone hotspot, then implement the Fog module on Gateway or cell phone to show the low latency, and light-weight compute resource; One other question I have is that the Neo4J it self can be hosted on any cloud platform that can still save the individual patients knowledge as graphical form. how would we use this in the gateway or cell-phone equipment ? 

Author Response

To the reviewer: Thank you for dedicating the time to evaluate our manuscript. Below you will find the detailed responses to your comments. All related revisions have been incorporated in the resubmitted documents.

Comment 1: Authors introduce a Fog layer for data processing and exchange, but all the tests ran on local laptop; a better way is to set up some real IoT devices e.g., raspberry pi to send data, via Gateway device or cell phone hotspot, then implement the Fog module on Gateway or cell phone to show the low latency, and light-weight compute resource;

Response 1: The comment is appropriate given the proof-of-concept nature of the work presented here. Thank you. To make the need for real devices explicit, we have added the following point to the Limitations and Future Work section:

• Data sources: Health monitoring devices have been simulated in this work because the scope of the proposal was Fog nodes. The use of real IoMT devices as data sources may impose new requirements, which will be addressed in future work.

Comment 2: One other question I have is that the Neo4J it self can be hosted on any cloud platform that can still save the individual patients knowledge as graphical form. how would we use this in the gateway or cell-phone equipment? 

Response: 2 Indeed, Neo4j is a lightweight implementation that can be deployed either in the Cloud or on resource-constrained nodes (as demonstrated by the results of this work). There are even initiatives to deploy Neo4j on mobile systems —particularly those running Android— which would shift the processing and storage of monitoring data to the Edge instead of the gateway (Fog nodes) used here. It is certainly an idea worth considering and investigating in the future. Thank you very much for the comment.

Author Response File: Author Response.pdf

Reviewer 2 Report

Comments and Suggestions for Authors

The article “Fog computing and graph-based databases for remote health monitoring in IoMT settings” demonstrates high originality through its novel integration of fog computing and Neo4j for IoMT, and it effectively addresses the research gap by tackling the limitations of cloud-centric IoMT systems while proposing a scalable, low-latency alternative. The applications are strong, with clear implications for real-world healthcare and continuous patient monitoring. Limitations and future work are well discussed, showing critical reflection and awareness of the study’s boundaries. Key strengths include a clear methodology, robust experimental design, practical relevance, and use of recent references. However, some weaknesses remain, particularly in the abstract, which could more clearly highlight the research gap, and in the discussion, which provides limited analysis of unexpected findings. The paper requires several minor revisions before considering for acceptance. In the abstract, the research gap must be stated explicitly, with a clearer emphasis on why combining Neo4j with Fog computing is significant for real-world IoMT. The introduction would benefit from a sharper problem statement directly linking latency and heterogeneity to the proposed solution, along with a more explicit integration of recent 2024–2025 references to highlight novelty. In the related work section, a short comparative summary should be added to clarify how this study advances beyond blockchain, fog, edge, and GDB approaches. Methodology edits ensuring consistent Cypher query syntax in Table 3, and slightly expanding the dataset description. Every figure should include a brief explanatory description following the caption to provide additional context and enhance clarity for the reader. In the results, Figures 5–7 need axis labels and units checked for clarity, the caption for Figure 7 should be rephrased for precision, and a brief interpretation should be added to explain why latency increases by orders of magnitude. The discussion should further analyze unexpected findings (e.g., minimal effect of query complexity on latency), expand on real-world applications in clinical or home monitoring settings, and better articulate the limitations posed by the simplified schema. The conclusion should more strongly emphasize the novelty of being the first to test Neo4j in fog-based IoMT at this scale, explicitly highlight practical impacts such as cost savings and efficiency, and connect future work to specific use cases like ML-based anomaly detection. References should be standardized for consistent style and alignment with MDPI formatting, while captions and tables require minor corrections, including expanding Figure 3’s caption, fixing line-break artifacts in Tables 1 and 3, and ensuring figures are of sufficient resolution. Together, these revisions focus on clarity, consistency, and deeper contextualization without altering the solid methodological contributions of the paper.

 

 

Author Response

To the reviewer: Thank you for dedicating the time to evaluate our manuscript. Below you will find the detailed responses to your comments. All related revisions have been incorporated in the resubmitted documents.

Reviewer 2: The article “Fog computing and graph-based databases for remote health monitoring in IoMT settings” demonstrates high originality through its novel integration of fog computing and Neo4j for IoMT, and it effectively addresses the research gap by tackling the limitations of cloud-centric IoMT systems while proposing a scalable, low-latency alternative. The applications are strong, with clear implications for real-world healthcare and continuous patient monitoring. Limitations and future work are well discussed, showing critical reflection and awareness of the study’s boundaries. Key strengths include a clear methodology, robust experimental design, practical relevance, and use of recent references.

However, some weaknesses remain, particularly in the abstract, which could more clearly highlight the research gap, and in the discussion, which provides limited analysis of unexpected findings. The paper requires several minor revisions before considering for acceptance.

Comment 1: In the abstract, the research gap must be stated explicitly, with a clearer emphasis on why combining Neo4j with Fog computing is significant for real-world IoMT.

Response 1: The abstract has been extended (in italics) to explicit state the research gap and how our approach links to real-world scenarios:

• Remote patient monitoring is a promising and transformative pillar of healthcare. However, deploying such systems at a scale—across thousands of patients and Internet of Medical Things (IoMT) devices—demands robust, low-latency, and scalable storage systems. [...]
• Combining Fog computing and Neo4j is a novel approach that meets the latency and real-time data ingestion requirements of IoMT environments. Therefore, it is suitable for supporting delay-sensitive monitoring programmes, where rapid detection of anomalies is critical (e.g. a prompt response to cardiac emergencies or early detection of respiratory deterioration in patients with chronic obstructive pulmonary disease), even at a large scale.

Comment 2: The introduction would benefit from a sharper problem statement directly linking latency and heterogeneity to the proposed solution, along with a more explicit integration of recent 2024–2025 references to highlight novelty.

Response 2: Addressing this comment, we have added the following paragraph at the end of the introduction, explicitly linking the IoMT challenges mentioned—latency and heterogeneity—with the solution we propose. We have also strengthened the timeliness and relevance of the problem by incorporating several works published in 2025 that highlight ongoing concerns regarding latency and interoperability in IoMT systems.

• Latency and device interoperability requirements are major unresolved challenges for IoMT [6-8]. Our proposal seeks to address these issues by combining the deployment of containerised Fog nodes, which move data processing and storage closer to the patient, shortening response time in latency-sensitive applications, and enabling the integration of heterogeneous devices via standardised data schemes.

Comment 3: In the related work section, a short comparative summary should be added to clarify how this study advances beyond blockchain, fog, edge, and GDB approaches.

Response 3: Following the reviewer's recommendation, we have included the following paragraph at the end of the Related work section in order to explain the contributions of our work compared to recent literature:

• Related work highlights the relevance of IoMT and the application of FC models in these settings. Nevertheless, most of the contributions focus on particular issues, such as security or resource optimisation, disregarding scalability or real-time performance. On the other hand, approaches implementing GDBs in healthcare do not have continuous patient monitoring as a use case. Our proposal represents a novel contribution by focusing the application of FC-based IoMT on real-time monitoring scenarios where latency, scalability, and Fog node performance issues are crucial. The use of Neo4j to store and process large volumes of data in real time also represents an innovative contribution, since this type of database has not been evaluated in such critical scenarios in terms of data volume, transmission frequency, and response time.

Comment 4: Methodology edits ensuring consistent Cypher query syntax in Table 3 and slightly expanding the dataset description.

Response 4: Table 3 and Cypher syntax have been reviewed to ensure consistency. Additionally, the dataset description has been expanded with the following text (new in italics):

• With the aim of using real data in the experiments, the BIG IDEAs Lab Glycemic Variability and Wearable Device Data (version 1.1.2), freely available on PhysioNet repository \citep{ref34} was utilised. It includes physiological data (e.g., tri-axial accelerometry, electrodermal activity, temperature, etc.) collected by wearable devices from individuals (9 women and 7 men) aged 35-65 years with elevated glucose levels, ranging from normal to pre-diabetic during 10 days. The following variables were used: interstitial glucose concentration (mg/dL), skin temperature (ºC), heart rate (beats per minute), blood pressure (mmHg), and oxygen saturation (\%). The data files contained a two-column frame format with the timestamp in the first column and the related measured values in the second one. The data did not require any preprocessing to be used in the experiments.    

Comment 5: Every figure should include a brief explanatory description following the caption to provide additional context and enhance clarity for the reader.

Response 5: Figures captions have been extended to include more information promoting clarity and understanding. Thank you.

Comment 6: In the results, Figures 5–7 need axis labels and units checked for clarity, the caption for Figure 7 should be rephrased for precision, and a brief interpretation should be added to explain why latency increases by orders of magnitude.

Response 6: Figures 5-7 have been modified regarding the reviewer’s comments as well as the caption of Figure 7. Thank you.

Regarding interpretation of Figure 7, the following sentences have been extended (in italics):

• The latency increased by up to two orders of magnitude between Scenarios 1 and 11. This is expected given that scenario 1 has 5,000 stored nodes and scenario 11 has 12 million nodes. This increase in nodes and relationships is responsible for the increased response time of Neo4j. Nevertheless, all queries were executed in less than 500 ms, meeting the latency requirements for real-time clinical applications.

Comment 7: The discussion should further analyze unexpected findings (e.g., minimal effect of query complexity on latency), expand on real-world applications in clinical or home monitoring settings, and better articulate the limitations posed by the simplified schema.

Response 7: the discussion has been extended to include the unexpected findings and real-world applications that could benefit with this solution:

• The results demonstrated Neo4j's strong scalability and efficiency, handling millions of observations and complex node relationships with minimal resource use. The low query latency (<500 ms) even in extreme scenarios involving over 12,000 devices transmitting data every 50 ms supports Neo4j's suitability for supporting real-time triage in home-monitoring programmes for patients with heart failure, continuous gait and tremor tracking in Parkinson’s disease, or early detection of respiratory deterioration in COPD, where rapid anomaly detection is essential. Additionally, Neo4j demonstrated consistent response times even as query complexity increased, a highly relevant factor when aiming to identify patterns and risk events in highly correlated health data. Given Neo4j’s versatility as a healthcare data warehouse, future work will explore the deployment of ML algorithms for the automated exploitation of monitoring data.
• The resource consumption remained well below the critical thresholds, highlighting the appropriateness of this approach for resource-constrained Fog nodes with Neo4j. This finding indicates that this architecture could run on cost-effective Fog nodes placed in community clinics, emergency transport units, or long-term care facilities without requiring specialised hardware.

Regarding limitations of the simplified schema, the related statement has been modified:

• Schema complexity: The data model used was intentionally simple. Although this allowed us to isolate performance metrics under controlled conditions, it does not fully reflect the complexity of real-world clinical graphs. Future assessments should incorporate richer schemas, even those based on medical ontologies, to validate Neo4j's performance under more heterogeneous and densely connected data;

Comment 8: The conclusion should more strongly emphasize the novelty of being the first to test Neo4j in fog-based IoMT at this scale, explicitly highlight practical impacts such as cost savings and efficiency, and connect future work to specific use cases like ML-based anomaly detection.

Response 8: the conclusion has been extended to emphasize the novelty of the approach:

• In summary, our work represents a novel and promising approach that combines FC and Neo4j to meet IoMT environments’ latency and real-time data ingestion requirements. Furthermore, the use of Neo4j to store and process large volumes of data in real time also represents an innovative contribution, since this type of database has not been evaluated in such critical scenarios in terms of data volume, transmission frequency, and response time. Finally, the observed low resource consumption makes this approach suitable for large-scale, population-level deployments.

The connection to specific ML-based use cases is included as:

• Additionally, Neo4j demonstrated consistent response times even as query complexity increased, a highly relevant factor when aiming to identify patterns and risk events in highly correlated health data. Given Neo4j’s versatility as a healthcare data warehouse, future work will explore the deployment of ML algorithms for the automated exploitation of monitoring data.

Comment 9: References should be standardized for consistent style and alignment with MDPI formatting,

Response 9: All the references have been carefully reviewed, and changes have been made when appropriate.

Comment 10: while captions and tables require minor corrections, including expanding Figure 3’s caption, fixing line-break artifacts in Tables 1 and 3, and ensuring figures are of sufficient resolution.

Response 10: Caption of Figure 3 has been modified to be more illustrative. Now it says:

• Example of the Neo4j data model used in the experiments. It shows one patient, one device, and three observations with their relationships.

Problems of Tables 1 and 3 have been fixed, and the resolution of all the figures has been increased. Thank you.

Together, these revisions focus on clarity, consistency, and deeper contextualization without altering the solid methodological contributions of the paper.

Author Response File: Author Response.pdf

Reviewer 3 Report

Comments and Suggestions for Authors

The paper titled “Fog Computing and Graph-Based Databases for Remote Health Monitoring in IoMT Settings” presents a well-thought-out study that combines fog computing and graph databases to enable scalable and low-latency healthcare monitoring. The topic is current, relevant, and well within the scope of the journal, addressing a growing need for efficient data management in medical IoT systems.

The manuscript is well-organized and easy to follow. The introduction provides clear motivation and background, while the related work section gives a good overview of existing research and where this work fits in. The methods are explained in enough detail to ensure reproducibility, and the figures and tables are clear and well-presented. The results convincingly show that Neo4j performs efficiently even under heavy workloads, making it a promising choice for real-time healthcare data processing.

The discussion connects the technical findings to broader implications, emphasizing the importance of low-latency and scalable fog architectures in healthcare applications. The limitations are also acknowledged honestly, which adds credibility to the study. Overall, the research makes a valuable contribution to the IoMT field.

A few areas could be improved to make the paper even stronger. The dataset section could include more details about the data types and any preprocessing done. Adding a brief comparison with other database models would help clarify why Neo4j stands out.

The practical relevance could be emphasized by linking the results to real-world clinical use cases, such as patient alert systems or hospital monitoring setups.

The security section, though informative, could benefit from specific implementation examples like encryption or access control methods. Updating the latency results in milliseconds instead of seconds would also improve clarity.

The figures and tables are neat, but captions could be slightly more descriptive. Including short definitions for technical terms such as “Cypher” and “FHIR” in the abbreviation list would make the paper more accessible to a wider audience.

Author Response

To the reviewer: Thank you for dedicating the time to evaluate our manuscript. Below you will find the detailed responses to your comments. All related revisions have been incorporated in the resubmitted documents.

Reviewer 3: The paper titled “Fog Computing and Graph-Based Databases for Remote Health Monitoring in IoMT Settings” presents a well-thought-out study that combines fog computing and graph databases to enable scalable and low-latency healthcare monitoring. The topic is current, relevant, and well within the scope of the journal, addressing a growing need for efficient data management in medical IoT systems.

The manuscript is well-organized and easy to follow. The introduction provides clear motivation and background, while the related work section gives a good overview of existing research and where this work fits in. The methods are explained in enough detail to ensure reproducibility, and the figures and tables are clear and well-presented. The results convincingly show that Neo4j performs efficiently even under heavy workloads, making it a promising choice for real-time healthcare data processing.

The discussion connects the technical findings to broader implications, emphasizing the importance of low-latency and scalable fog architectures in healthcare applications. The limitations are also acknowledged honestly, which adds credibility to the study. Overall, the research makes a valuable contribution to the IoMT field.

A few areas could be improved to make the paper even stronger.

Comment 1: The dataset section could include more details about the data types and any preprocessing done.

Response 1: The dataset description has been expanded with the following text new in italics):

• With the aim of using real data in the experiments, the BIG IDEAs Lab Glycemic Variability and Wearable Device Data (version 1.1.2), freely available on PhysioNet repository [34] was utilised. It includes physiological data (e.g., tri-axial accelerometry, electrodermal activity, temperature, etc.) collected by wearable devices from individuals (9 women and 7 men) aged 35-65 years with elevated glucose levels, ranging from normal to pre-diabetic during 10 days. The following variables were used: interstitial glucose concentration (mg/dL), skin temperature (ºC), heart rate (beats per minute), blood pressure (mmHg), and oxygen saturation (\%). The data files contained a two-column frame format with the timestamp in the first column and the related measured values in the second one. The data did not require any preprocessing to be used in the experiments.

Comment 2: Adding a brief comparison with other database models would help clarify why Neo4j stands out.

Response 2: The presented data model can be implemented in any graph-oriented database; it is not exclusive to Neo4j. The relevance of Neo4j is supported by literature included in Related work section, and it is not the focus of this work. Regarding the data model itself, as explained in Limitations, its complexity is intentionally simple. Future work will focus on using a more complex data model based on medical ontologies that better reflects real-world systems. Thank you.

Comment 3: The practical relevance could be emphasized by linking the results to real-world clinical use cases, such as patient alert systems or hospital monitoring setups.

Response 3: the discussion has been extended to include examples of real-world applications that could benefit with this solution:

• The low query latency (<500 ms) even in extreme scenarios involving over 12,000 devices transmitting data every 50 ms supports Neo4j's suitability for supporting real-time triage in home-monitoring programmes for patients with heart failure, continuous gait and tremor tracking in Parkinson’s disease, or early detection of respiratory deterioration in COPD, where rapid anomaly detection is essential. […]
• The resource consumption remained well below the critical thresholds, highlighting the appropriateness of this approach for resource-constrained Fog nodes with Neo4j. This finding indicates that this architecture could run on cost-effective Fog nodes placed in community clinics, emergency transport units, or long-term care facilities without requiring specialised hardware.

Comment 4: The security section, though informative, could benefit from specific implementation examples like encryption or access control methods.

Response 4: The following sentences regarding security concerns have been extended (in italics) to include implementation examples as the reviewer states. Also, two references ([28] and [29]) have been added to bibliography focusing on security solutions for Internet of Medical Things.

• These frameworks recommend strategies, including comprehensive risk management, firewall deployment to secure communications with cloud services, and rigorous access control through identity and access management tools. For instance, implementing Role-Based Access Control (RBAC) ensures that only qualified medical personnel can access specific patient records, while Attribute-Based Access Control (ABAC) provides more granular control based on context (e.g., time of day or location) [28]. They also emphasize the importance of encrypting stored and transmitted data, such as using Transport Layer Security (TLS) 1.3 for data in transit and the Advanced Encryption Standard (AES-256) for data at rest [29], as well as deploying intrusion detection and anti-malware systems, and ensuring resilience through replication and backup mechanisms.

Comment 5: Updating the latency results in milliseconds instead of seconds would also improve clarity.

Response 5: Both Table 4 and Figure 7 have been modified to express latency in milliseconds.

Comment 6: The figures and tables are neat, but captions could be slightly more descriptive. Including short definitions for technical terms such as “Cypher” and “FHIR” in the abbreviation list would make the paper more accessible to a wider audience.

Response 6: The entire article has been reviewed to clarify every acronym and include it in the list of abbreviations (for example, FHIR). We did not include Cypher because it is not an acronym. Regarding the titles of the figures and tables, these have been reviewed and expanded to improve their clarity. Thank you.

Author Response File: Author Response.pdf

Round 2

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have addressed the reviewers’ comments in their revision, and the manuscript is now suitable for acceptance.

Author Response

Reviewer 2

The authors have addressed the reviewers’ comments in their revision, and the manuscript is now suitable for acceptance.

Response: Thank you for your careful review and positive assessment. We appreciate the time dedicated to evaluating our work.