Introduction

Big data, characterized by its volume, velocity, and variety, is transforming numerous industries, with healthcare being a major driver of this transformation. Volume refers to the massive amount of data generated, velocity highlights the speed at which data is produced and requires real-time processing, and variety encompasses the different formats of data, including text records, medical images, and sensor data1,2. Medical or HBD, as shown in Fig. 1, represents a vast and continuously expanding pool of data comprised of patient records, continuous monitoring data, medical imaging, and more. This data is generated at a high velocity, mirroring the constant interaction of patients with the healthcare system and requiring near real-time analysis for optimal care delivery3. Healthcare data is continuously produced and necessitates rapid analysis for effective treatment. Additionally, healthcare big data exhibits variety, encompassing diverse formats such as text (patient records, diagnoses), numerical data (vital signs, lab test results), images (X-rays, MRIs), and even video recordings (surgical procedures). This diversity reflects the complex and multifaceted nature of medical information within the expansive data landscape4,5. It is estimated that healthcare big data shares 30% of the overall big data6.

Fig. 1
figure 1

Big data in healthcare3.

By 2030, the global big data analytics market is expected to reach $349.56 billion, with healthcare being a significant contributor to this growth7. In the U.S., healthcare’s use of big data analytics is projected to grow by 36% annually through 2025, which could reduce healthcare costs by 8%, translating to over $300 billion in value each year7. A compelling example of big data’s impact on healthcare is Michigan, where post-surgical death rates were reduced by 67% due to big data analytics, illustrating its potential to revolutionize patient outcomes8,9.

However, the rapid expansion of Internet-connected devices, projected to reach 75 billion by 2030, is causing significant strain on public networks, particularly impacting the healthcare sector. Healthcare systems generate massive volumes of data from sources such as EHR, continuous monitoring devices, and medical imaging systems10,11. This data is predominantly processed through cloud-based infrastructures, which are increasingly overwhelmed by the massive volume and the real-time processing demands of HBD12.

As healthcare becomes more reliant on data-driven decision-making, the ability to process and analyze this data in real time is crucial for timely diagnoses, treatment interventions, and patient monitoring. However, transferring large datasets to centralized cloud servers introduces substantial delays, leading to network congestion that disrupts the flow of critical information. These delays can have serious consequences for patient care, where immediate insights are often necessary for life-saving decisions.

Furthermore, network congestion further compounds the problem by limiting healthcare providers’ access to real-time analytics and actionable insights. Current solutions, such as fog and mobile edge computing, offer potential but are often constrained by limited resources and scalability issues, making them unsuitable for the increasing data loads of future healthcare systems.

Addressing these challenges requires a robust, scalable framework that can reduce delays and alleviate network congestion. Such a framework must be capable of efficiently managing the complexities of data-intensive healthcare applications, ensuring that healthcare systems can meet increasing data demands without compromising patient outcomes.

The primary objective of this research is to introduce and evaluate the effectiveness of RC as a scalable solution to address the critical challenges posed by the massive volume and real-time demands of healthcare data-driven applications. Traditional cloud-based processing proves inadequate due to network congestion and latency issues, hindering the timely delivery of critical insights required for patient care.

This study assesses, as shown in Fig. 2, how RC, by utilizing strategically positioned regional servers, mitigates these limitations by enabling localized collection, processing, and storage of healthcare data. The research evaluates the ability of RC to reduce latency, alleviate network congestion, and support real-time data analysis, essential for healthcare providers to deliver personalized care and optimize treatment strategies. Additionally, the study explores how RC enhances real-time monitoring, improves decision-making, and contributes to a more efficient and responsive healthcare system. By focusing on RC, this research contributes to the development of a resilient, low-latency infrastructure that meets the growing data demands of healthcare applications.

Fig. 2
figure 2

Proposed structure of regional computing for healthcare big data.

This paper introduces a novel framework for managing HBD through the implementation of RC in the context of data generated by medical equipment, such as IOMT devices. The key contributions of this research are as follows:

  1. 1.

    This framework proposes the initial processing and storage of medical data at regional servers, which are strategically located to minimize delays. By processing data closer to its source, the framework enhances the speed and efficiency of data handling, crucial for real-time healthcare applications.

  2. 2.

    The system includes a dynamic offloading mechanism that monitors the performance. If the regional server’s performance exceeds that of the cloud, particularly during peak hours, the data is automatically sent to the cloud. This ensures optimal resource utilization and timely access to critical healthcare information.

  3. 3.

    The framework leverages the scalability of regional computing, offering resource capabilities near to the cloud while maintaining the efficiency of edge-level proximity. Regional servers, strategically deployed, provide near-cloud computational power, enabling efficient handling of medical big data.

The rest of the paper is organized as follows.

Section “Background” presents a review of literature and projects related to healthcare big data and data offloading. Section “Proposed methodology” details the proposed methodology, addressing limitations in existing approaches. Section “Evaluation” evaluates the proposed methodology through prototyping and experimentation. Section “Discussion” analyzes the roles of regional and cloud computing in healthcare big data, highlighting the advantages of regional computing over cloud solutions. Finally, Section “Conclusion” provides the study’s conclusions.

Background

The background is divided into two sections. The first section focuses on the sensors and devices currently employed in medical centers, while the second section addresses the techniques used for big data offloading in the market and literature.

Internet of medical things

The IOMT, as shown in Fig. 3, is transforming healthcare by interconnecting medical devices and sensors, enabling continuous health monitoring and data collection13. This massive amount of data, referred to as HBD, holds promise for improving healthcare delivery through personalized treatment plans, early diagnostics, and predictive analytics. However, the unprecedented scale, variety, and speed of IOMT data present significant challenges for storage, real-time processing, and meaningful analysis14,15. Tackling these challenges requires innovative solutions in data management, storage, and analytics to extract actionable insights from the collected data.

Fig. 3
figure 3

Internet of medical things (IOMT) sensors.

Wearable devices and body area sensor networks (BASN)

Wearable devices play a pivotal role in IOMT, forming the foundation of Body Area Sensor Networks (BASN), also referred to as Wireless Body Area Networks (WBAN)16. These sensors continuously monitor physiological parameters by being worn on the body, embedded in clothing, or implanted. BASN are vital in chronic disease management, real-time health monitoring, and early detection of health issues17. However, the substantial volumes of continuous, high-frequency data they generate contribute significantly to the big data challenges in healthcare.

Blood pressure sensors generate real-time data on systolic, diastolic, and mean arterial pressure, which is vital for long-term cardiovascular health monitoring18. The continuous readings create large datasets used in predictive analytics, significantly aiding early diagnosis and personalized treatment plans in cardiovascular care19.

Pulse oximeters measure oxygen saturation (SpO2) and pulse rate, generating essential data for monitoring patients with respiratory conditions like COPD or asthma20,21. The continuous streams of oxygen saturation data support real-time interventions and long-term trend analysis for personalized respiratory care.

Glucose sensors continuously monitor blood sugar levels, generating real-time alerts for abnormal glucose levels, which is crucial for diabetes management22. This data enhances predictive analytics in diabetes care, improving personalized treatment by preventing severe fluctuations in glucose levels and enabling timely health adjustments23.

EEG sensors monitor brain activity, commonly used for diagnosing neurological conditions such as epilepsy24. These devices produce large datasets capturing electrical brain activity in real-time, which are crucial for developing personalized treatment strategies in neurology through big data analytics25.

ECG sensors track heart activity, producing real-time data on heart rhythms and electrical signals26. The large datasets generated are essential for detecting cardiovascular anomalies, contributing to the broader pool of healthcare big data that aids in the early detection and treatment of heart conditions27.

Respiration sensors measure breathing patterns, generating critical data for managing respiratory conditions like sleep apnea and chronic lung diseases28. The datasets produced by these sensors support real-time monitoring and long-term analysis in predictive healthcare analytics for respiratory health29.

Accelerometers and Motion sensors, commonly embedded in fitness trackers and smartwatches, monitor physical activity by detecting movement patterns30. The data generated supports preventive care strategies by contributing to large-scale health and fitness datasets, helping predict and monitor mobility-related health issues31.

Medical imaging devices

Medical imaging devices like Magnetic Resonance Imaging (MRI), Computed Tomography (CT), ultrasound, and X-ray machines generate detailed diagnostic images that contribute to large, complex datasets. These imaging devices are crucial for the early detection, diagnosis, and treatment of various health conditions32. However, the high-resolution images produced require robust storage and data processing capabilities, thereby amplifying the challenges of big data in healthcare.

MRI scanners generate vast amounts of detailed data on internal tissues and organs33. These high-resolution images are essential for diagnosing neurological disorders and create large datasets that necessitate advanced storage solutions and AI-powered analytics for efficient processing and analysis34.

CT scanners produce detailed cross-sectional images of the body, generating extensive datasets that support medical diagnosis35. The large volumes of CT data require sophisticated machine learning algorithms for real-time analysis, which enhances diagnostic accuracy and personalized treatment plans.

Ultrasound devices provide real-time imaging for diagnostic and monitoring purposes. These devices generate high-frequency image data used in various medical applications, from prenatal care to cardiology36. Processing ultrasound data necessitates efficient data management to support predictive analytics and advanced healthcare research37.

X-ray machines are widely used for diagnosing fractures, infections, and other skeletal issues. The data produced from X-ray images contributes to the growing repository of medical big data, aiding in large-scale analytics for trend identification and diagnostic improvements38,39.

In-home care and remote monitoring systems

IOMT extends beyond clinical settings, with in-home care devices enabling remote patient monitoring. These devices are particularly beneficial for elderly individuals and patients with chronic conditions, as they allow for continuous tracking without frequent hospital visits. The data generated through remote monitoring systems contributes to the larger healthcare data pool, requiring efficient data storage and analytics for real-time interventions and long-term patient care40.

Smart Glucose Monitors continuously monitor blood glucose levels, providing real-time data for diabetes management. This data supports both short-term adjustments and long-term trend analysis for optimizing treatment plans41.

Smart Thermometers track body temperature and provide early warnings of infections. The data generated by these devices is integrated into healthcare databases, supporting predictive healthcare analytics for early diagnosis and intervention42.

Fall Detection Systems, equipped with motion sensors, monitor movement patterns to detect falls, particularly among elderly patients. The data generated assists caregivers in intervening quickly while also contributing to big data analytics aimed at improving fall prevention strategies.

Assistive technologies

Assistive technologies within IOMT significantly enhance the quality of life for individuals with disabilities or elderly patients. These technologies generate continuous data streams that monitor health status and assist with daily activities43. This real-time data contributes to large-scale analytics for improving patient care and enhancing assistive technologies.

Smart Wheelchairs utilize Internet of Things (IOT) to monitor the user’s environment, generating data that improves mobility and safety44. This data supports real-time adjustments and contributes to healthcare analytics aimed at enhancing mobility solutions.

Connected Hearing Aids adjust sound levels in real time and transmit data on user hearing patterns to healthcare providers, aiding in personalized care and contributing to larger healthcare datasets45.

Virtual Reality (VR)/Augmented Reality (AR) Systems are utilized for cognitive and physical rehabilitation, generating data that supports therapeutic progress monitoring and rehabilitation outcomes analysis46.

Cognitive Assistance Devices provide real-time reminders and health monitoring for elderly or cognitively impaired individuals. The data collected is vital for ensuring safety and contributes to personalized care strategies through big data analytics47.

Offloading techniques

Medical 4.0 technologies have introduced a vast array of devices and systems that generate massive volumes of big data, particularly in the healthcare sector. These include sensors, wearable devices, mobile applications, and virtual reality, all of which contribute to the growing IOMT. In this evolving landscape, specialized techniques are needed to process and store the immense amounts of data produced48. The IOT, mobile computing, artificial intelligence, and big data analytics further amplify the challenge, demanding more robust and intelligent systems to manage the continuous flow of information49.

To handle this influx of data, cloud computing has emerged as a popular solution, offering a scalable and efficient method for managing healthcare big data. Many healthcare institutions have adopted cloud computing to implement advanced healthcare information systems50. These systems provide comprehensive data storage and processing capabilities, facilitating everything from patient monitoring to decision-making in real time. However, researchers have identified significant organizational barriers when implementing cloud-based systems, often related to system integration and management51,52. Furthermore, while cloud computing remains effective for large-scale data storage, it faces challenges such as network congestion, latency, and delayed responses, particularly in time-sensitive applications like healthcare53. These limitations have raised concerns about the reliability of cloud-based solutions for critical healthcare operations.

To address these challenges, Mobile Edge Computing (MEC) has been introduced as a way to bring data processing closer to the source, particularly in healthcare scenarios involving the IOMT. MEC helps reduce the latency and bandwidth issues commonly associated with cloud computing by processing data at the edge of the network. Studies have examined the use of MEC for WBAN, where patient data is transmitted from sensors to nearby edge devices for real-time analysis54. This reduces reliance on the cloud and enhances the system’s responsiveness. Additionally, new frameworks have been proposed to optimize edge network cooperation, improving task efficiency and performance in edge computing55. Despite these advantages, MEC systems still face limitations related to scalability and resource allocation, particularly when large datasets need to be processed simultaneously53,56,57. In addition to MEC, researchers have turned to edge and fog computing as viable alternatives for handling real-time healthcare applications. Edge computing offers immediate data processing at or near the data source, making it a suitable solution for time-sensitive tasks such as analyzing patient health data58. For instance, healthcare systems utilizing edge computing have been designed to optimize resource allocation, reduce costs, and enhance user benefits through game theory-based approaches59. Similarly, the integration of edge computing into smart surveillance systems has demonstrated improvements in network bandwidth usage and response times60. While edge computing provides localized data processing, it still faces challenges when scaling to meet the demands of larger healthcare institutions.

Fog computing has also gained traction, particularly in scenarios requiring data processing at or near the data source, such as wearable medical devices. This approach reduces latency and eases the burden on network bandwidth, enabling real-time analytics for applications like remote patient monitoring and predictive healthcare interventions61. A notable advancement is the concept of a Smart e-Health Gateway, which leverages fog computing to provide local data storage, real-time processing, and embedded data mining in IoT-based healthcare networks62. While fog computing addresses issues like mobility, scalability, and reliability, it is not without its challenges, particularly when coordinating data cooperation across multiple healthcare institutions.

Another approach that has been explored is the use of cloudlets, small-scale data centers that are located closer to the data source than traditional cloud servers. While cloudlets have shown promise in managing healthcare big data, their scalability and resource limitations make them less suitable for handling large datasets during peak usage periods63. In such cases, cloud computing may offer greater scalability, but with the trade-off of higher latency and network congestion. Edge computing has similarly been employed to process medical data generated by IOT devices, although it struggles with the same scalability issues as cloudlets64. To tackle the challenges of data heterogeneity and irregularity, middleware and hybrid platforms combining fog and cloud computing have been proposed to ensure efficient data processing, classification, and storage65.

The literature highlights various attempts to address the challenges of managing healthcare big data through cloud, edge, and fog computing. While these technologies offer distinct advantages, such as localized data processing and reduced network latency, they also present limitations, particularly regarding scalability and data cooperation. As cloud computing faces issues with real-time decision-making and responsiveness, and edge computing struggles to scale, there is a need to explore alternative solutions. Regional computing, which combines the strengths of both cloud and edge computing, emerges as a promising approach to manage healthcare big data more effectively, especially in scenarios that require both scalability and real-time processing. Further research is needed to fully explore the potential of regional computing in addressing these critical challenges.

Proposed methodology

The healthcare system becomes more efficient as more data from IOMT is integrated into the collective network. Uploading data from every device to cloud servers is essential; however, each medical device may generate up to a terabyte of data per day, which is beyond the capacity of existing systems to transport, process, and store efficiently. As illustrated in Fig. 4, the proposed system seeks to process and store this medical big data closer to healthcare infrastructure to reduce latency and cost. The data is then transferred to the cloud during off-peak hours, ensuring minimal network load, as peak hours often lead to congestion, whereas off-peak periods are typically underutilized. The proposed model look at the performance (network and data-center), energy and cost model. The remaining part of this section, covers this in detail.

Fig. 4
figure 4

Proposed structure of regional computing for healthcare data-driven applications.

Delay model

The delay model is structured into three layers: the IOMT, responsible for managing all healthcare devices; regional computing, which handles the processing of healthcare big data near the devices; and cloud computing, which ensures permanent data storage and supports large-scale analysis. The following sections detail the operation of this methodology.

Internet of medical things (IoMT)

The IOMT layer includes the medical devices, and sensors. Data from these devices (\(w = \{w_{1}, w_{2}, w_{3}, \ldots , w_{m}\}\)) , such as wearable sensors, implantable medical devices, or external monitoring systems (\(d = \{d_{1}, d_{2}, d_{3}, \ldots , d_{n}\}\)), is transmitted to gateways through personal or local area networks, which act as collectors and edge for transferring data to the regional servers for processing and analysis. The medical sensors, such as Electrocardiogram (ECG) monitors, pulse oximeters, and glucose sensors, collect real-time health data, while gateways help ensure efficient data transmission to minimize latency and support immediate healthcare needs. This communication involves various delays during the data transmission process. These delays include transmission delay, propagation delay, processing delay, and queuing delay, each contributing to the overall time required for the data to reach its destination.

Most of the sensors are wirelessly connected to the gateway through a personal area network and wirelessly transmit the data. Transmission delay (\(T_{\text {tran}}\)) accounts for the time taken to transmit the data from the IOMT device (d) to the gateway. It is determined by factors including data (\(Wl\)), channel bandwidth (\(B\)), signal-to-noise ratio (\(SNR\)), modulation efficiency (\(M\)), and error rate (\(E\)). This relationship is expressed as:

$$\begin{aligned} T_{\text {tran}} = \frac{Wl \times M \times \text {SNR}}{B \times E} \end{aligned}$$
(1)

The propagation delay (\(T_{\text {prop}}\)) represents the time taken for the data to travel through the wireless medium. It depends on the distance (\(d\)) between the IOMT device and the gateway and the transmission speed (\(v\)) in the medium:

$$\begin{aligned} T_{\text {prop}} = \frac{d_{gateway}}{v} \end{aligned}$$
(2)

The processing delay (\(T_{\text {proc}}\)) reflects the time taken for the gateway to process the received data. It is determined by the data workload (\(Wl\)) and the processing rate of the gateway (\(R_{\text {proc}}\)):

$$\begin{aligned} T_{\text {proc}} = \frac{Wl}{Pr_{\text {gateway}}} \end{aligned}$$
(3)

Finally, the queuing delay (\(T_{\text {que}}\)) indicates the time the data spends in the gateway’s queue before being processed. This depends on the workload (\(Wl\)), packet arrival rate (\(\lambda\)), and the processing capacity (\(\mu\)) of the gateway:

$$\begin{aligned} T_{\text {que}} = \frac{Wl \times \lambda }{\mu } \end{aligned}$$
(4)

where \(Wl = \sum _{i=1}^{n} d_i\), workload generated by 1 to n medical devices.

Combining all these components, the total delay for data communication from IOMT devices to the gateway through the PAN or LAN can be expressed as:

$$\begin{aligned} T_{\text {Gatway}} = \frac{Wl \times M \times \text {SNR}}{B \times E} + \frac{d}{v} + \frac{Wl}{Pr_{\text {gateway}}} + \frac{Wl \times \lambda }{\mu } \end{aligned}$$
(5)

This Eq. (5) provides a comprehensive way to calculate the total delay in an IOMT layer, taking into account various factors such as data transmission, propagation, processing, and queuing delays.

Regional computing

To optimize network efficiency, the HBD generated by IOMT devices is temporarily stored on regional servers during peak hours and transmitted to the cloud during off-peak periods. This approach alleviates congestion on public networks and minimizes latency.

The regional layer consists of servers dedicated to processing and storing data from healthcare devices within a specific geographical area. These servers function as regional servers, aggregating information from various healthcare devices operating in their domain. Each device transmits data to the regional servers, which encompass parameters such as patient monitoring data, device status, environmental conditions, and other relevant information regarding health and safety.

This data from gateways to the regional servers is transmitted through fibre optic or other fast transmission medium. The transmission delay (\(T_{\text {tran}}\)) in this context depends on the data size (\(Wl\)), and the speed (\(v\)). The transmission delay can be expressed as:

$$\begin{aligned} T_{\text {tran}} = \frac{Wl}{v} \end{aligned}$$
(6)

The propagation, queuing and processing delay are the same as calculated for IOMT layer.

$$\begin{aligned} T_{\text {Regional}} = \frac{d}{v} + \frac{Wl}{Pr_{\text {regional}}} + \frac{L \times \lambda }{\mu } \end{aligned}$$
(7)

The Eqs. 5 and 7 demonstrate that the delay is primarily influenced by the total workload and the transmission distance. Therefore, by reducing both the network workload and the distance, the overall delay experienced by HBD can be significantly minimized.

The major part of the workload in this IOMT architecture is processed by regional computing units, significantly reducing the burden on central cloud infrastructure and, consequently, minimizing network congestion. By handling data closer to the source, regional computing limits the amount of traffic transmitted over the mainstream network, thus reducing the total traffic, \(Wl_{total}\), on the network. As a result, this approach helps maintain an optimal balance between workload and available bandwidth, \(B_{avail}\), as illustrated by the following congestion probability equation:

$$\begin{aligned} Con_{Prob} \approx \frac{Wl_{total}}{B_{avail}} \end{aligned}$$

here, \(Con_{Prob}\) denotes the probability of congestion, which is directly proportional to the total network traffic and inversely proportional to the available bandwidth. Since regional computing handles the bulk of the processing locally, \(Wl_{total}\) decreases, effectively lowering the likelihood of congestion.

Regional computing’s decentralized approach, by reducing the volume of data sent to the cloud, optimizes bandwidth usage and mitigates network congestion risks, ensuring faster data processing and enhanced real-time IOMT services. This architecture not only improves efficiency but also supports scalable healthcare solutions as IOMT devices proliferate.

Cloud computing

The regional layer manages real-time medical data from IOMT devices, while the cloud layer operates as a powerful backend that enhances data processing and storage capabilities. The regional layer relies on the cloud for extensive computing resources, transferring medical big data to the cloud during off-peak hours to utilize its advanced capabilities for comprehensive analysis and share the data globally for research and diagnostic purposes.

In contrast to the regional layer, the cloud hosts a vast amount of HBD generated from worldwide medical centres. It functions as a centralized repository for processing and storing this extensive dataset.

$$\begin{aligned} T_{\text {cloud}} = \frac{Wl}{Pr_{\text {cloud}}} \end{aligned}$$
(8)

Equation (8) illustrates the processing time (\(T_{\text {cloud}}\)) required to collectively analyze all medical workloads at cloud servers. Here, \(T_{\text {cloud}}\) represents the processing time, \(Wl\) is the total medical workload to be processed, and \(Pr_{cloud}\) is the processing rate of the cloud servers, denoting the volume of data processed per unit of time.

The total medical big data workload (\(Wl\)) is calculated as the summation of data produced by each IOMT device (\(d_i\)) from 1 to \(n\), as shown in Eq. (9):

$$\begin{aligned} Wl = \sum _{i=1}^{n} d_i \end{aligned}$$
(9)

Similarly, the propagation delay (\(T_{\text {prop}}\)) represents the time taken for the data to travel through the network. It depends on the distance (\(d_{cloud}\)) between the IOMT device and the cloud servers and the transmission speed (\(v\)) in the medium:

$$\begin{aligned} T_{\text {prop}} = \frac{d_{cloud}}{v} \end{aligned}$$
(10)

Analysis of Eqs. (9) and (10) indicates that the round-trip to the cloud incurs more delay than anticipated. This increased delay is primarily due to the cloud’s necessity to process substantial volumes of medical big data (\(Wl\)) and its distance (d). Additionally, propagation and queuing delays escalate in correlation with the growing workload and distance.

The cloud plays a crucial role in analyzing Medical Big Data (MBD) to derive insights into patient health, treatment effectiveness, and device performance. These insights improve healthcare delivery, providing real-time updates to healthcare providers and enhancing patient outcomes. Additionally, the cloud strengthens safety and security measures by detecting anomalies, identifying risks, and optimizing healthcare practices.

Energy model

In healthcare big data, energy consumption plays a critical role, especially when handling the vast amount of data generated by medical devices. Similar to delay, energy consumption is also impacted by the distance between devices. The energy consumption in HBD communication can be computed as:

$$\begin{aligned} \mathscr {E}_{\text {tran}} = \sum _{i=1}^{n} \left( \mathscr {E}_{\text {tran}}^{\text {sensor}}(i) + \mathscr {E}_{\text {tran}}^{\text {regional}}(i) \right) \end{aligned}$$
(11)

here, \(\mathscr {E}_{\text {tran}}^{\text {sensor}}(i)\) represents the energy used for data transmission from medical sensor \(i\) to the gateway, while \(\mathscr {E}_{\text {tran}}^{\text {regional}}(i)\) refers to the energy utilized for transferring data from the gateway to regional servers.

Where

$$\begin{aligned} \mathscr {E}_{\text {tran}}^{\text {sensor}}(i)\approx {Dis_{i, \text {gateway}} \cdot P_{i}^{\text {sensor}}}\cdot {{T_{i, \text {gateway}}}} \end{aligned}$$
(12)

and

$$\begin{aligned} \mathscr {E}_{\text {tran}}^{\text {regional}}(i) \approx {Dis_{\text {gateway}, \text {regional}} \cdot P_{\text {gateway}}^{\text {regional}}}\cdot {{T_{\text {gateway}, \text {regional}}}} \end{aligned}$$
(13)

In these equations, \(Dis_{i, \text {gateway}}\) denotes the distance between medical sensor \(i\) and the gateway, \(P_{i}^{\text {sensor}}\) represents the power consumption for data transmission by sensor \(i\), and \(T_{i, \text {gateway}}\) is the time taken for the data to reach the gateway. Similarly, \(Dis_{\text {gateway}, \text {regional}}\) represents the distance from the gateway to the regional server, \(P_{\text {gateway}}^{\text {regional}}\) is the power consumption for data transmission, and \(T_{\text {gateway}, \text {regional}}\) represents the transmission time from the gateway to the regional servers.

These equations demonstrate that energy consumption increases with the distance involved in data transmission, both from sensors to gateways and from gateways to regional servers through network.

$$\begin{aligned} \mathscr {E}_{\text {other}} = \mathscr {E}_{\text {pro}} + \mathscr {E}_{\text {stor}} + \mathscr {E}_{\text {cool}} + k \end{aligned}$$
(14)

Similarly, \(\mathscr {E}_{\text {other}}\) encompasses the energy used for other operations such as data processing (\(\mathscr {E}_{\text {pro}}\)), storage (\(\mathscr {E}_{\text {stor}}\)), and cooling (\(\mathscr {E}_{\text {cool}}\)) in medical data centers.

The total energy consumption for the IOMT system is calculated as:

$$\begin{aligned} \mathscr {E}_{\text {total}} = \mathscr {E}_{\text {tran}} + \mathscr {E}_{\text {other}} \end{aligned}$$
(15)

where \(\mathscr {E}_{\text {total}}\) represents the overall energy consumption, while \(\mathscr {E}_{\text {tran}}\) denotes the total energy consumed during data offloading from IOMT devices.

It is important to note that:

$$\begin{aligned} Cost_{\text {oper}} \propto \mathscr {E} \end{aligned}$$
(16)

There is a direct relationship between energy consumption (\(\mathscr {E}\)) and operational costs (\(Cost_{\text {oper}}\)). As energy consumption increases, the operational costs of managing and processing medical big data also rise.

The equations above indicate that energy consumption escalates as the distance between IOMT sensors and regional servers increases. Moreover, the increasing workload can congest network channels and computing processors, generating additional heat and further energy consumption (as shown in Eq. 16). Consequently, this model shows that energy consumption for cloud-based processing of medical big data is significantly higher. However, when workloads are processed by regional servers, energy requirements are reduced, making regional computing a more energy-efficient solution for HBD.

Cost model

In prior sections, we examined how delay, congestion, and energy consumption escalate with the increasing distance between medical devices and processing units within the IOMT framework. This section highlights the cost dynamics associated with these parameters for HBD. The total cost can be expressed using the following equation:

$$\begin{aligned} Cost_{t} = Cost_{tr} + Cost_{p} + Cost_{pr} + Cost_{col} \end{aligned}$$
(17)

where \(Cost_{t}\) signifies the total cost, \(Cost_{tr}\) denotes the transmission cost, \(Cost_{p}\) is the propagation cost, \(Cost_{pr}\) refers to the processing cost, and \(Cost_{col}\) accounts for the cooling cost associated with medical data storage and processing facilities.

The transmission cost, \(Cost_{tr}\), encompasses two components: the expense related to transmitting data from IOMT devices to central data aggregation points and the cost incurred from these aggregation points to regional computing servers.

For the transmission from IOMT devices to gateway, the cost can be formulated as:

$$\begin{aligned} \begin{aligned} C_{\text {trn, gateway}}&= \sum _{i=1}^{n} \sum _{j=1}^{m} \left( C_{\text {rate, dev}} \cdot L_{i,\text {gateway}} w_j + \right. \\&\quad \left. C_{\text {time, dev}} \cdot T_{i,\text {gateway}} + C_{\text {energy, dev}} \cdot E_{i,\text {agg}} + \right. \\&\quad \left. C_{\text {bandwidth, dev}} \cdot B_{i,\text {gateway}} + C_{\text {fixed, dev}} \right) \end{aligned} \end{aligned}$$
(18)

In this formula, \(n\) represents the number of IOMT devices, and \(m\) denotes the number of workload tasks generated by these devices. \(C_{\text {rate, dev}}\) signifies the cost per unit of data transmitted, with \(L_{i,\text {gateway}} w_j\) indicating the data amount from IOMT device \(i\) for workload \(j\). \(C_{\text {time, dev}}\) refers to the cost per unit of time for this transmission, while \(T_{i,\text {gateway}}\) represents the required transmission time. \(C_{\text {energy, dev}}\) denotes the cost per unit of energy consumed, with \(E_{i,\text {gateway}}\) representing the energy utilized in the transmission from IOMT devices to data aggregation points. Additionally, \(C_{\text {bandwidth, dev}}\) indicates the cost per unit of bandwidth used, and \(B_{i,\text {gateway}}\) signifies the bandwidth utilized. \(C_{\text {fixed, dev}}\) is the fixed cost associated with each transmission event from IOMT devices.

For the transmission from gateway to regional computing servers, the cost can be formulated as:

$$\begin{aligned} \begin{aligned} C_{\text {trn, rc}}&= \sum _{i=1}^{n} \sum _{j=1}^{m} \left( C_{\text {rate, gateway}} \cdot l_{\text {gateway},\text {rc}} w_j + \right. \\&\quad \left. C_{\text {time, gateway}} \cdot T_{\text {gateway},\text {rc}} + C_{\text {energy, gateway}} \cdot E_{\text {gateway},\text {rc}} + \right. \\&\quad \left. C_{\text {B, gateway}} \cdot B_{\text {gateway},\text {rc}} + C_{\text {fixed, gateway}} \right) \end{aligned} \end{aligned}$$
(19)

In this formula, \(C_{\text {rate, gateway}}\) signifies the cost per unit of data transmitted from gateway, with \(l_{\text {gateway},\text {rc}} w_j\) representing the data amount for workload \(j\). The cost per unit of time for this transmission is \(C_{\text {time, gateway}}\), with \(T_{\text {gateway},\text {rc}}\) indicating the time taken. \(C_{\text {energy, gateway}}\) denotes the cost per unit of energy consumed during this transmission, while \(E_{\text {gateway},\text {rc}}\) represents the energy used in the transmission from the gateway to regional computing servers. \(C_{\text {B, gateway}}\) is the cost per unit of bandwidth utilized, and \(B_{\text {gateway},\text {rc}}\) signifies the bandwidth utilized. Lastly, \(C_{\text {fixed, gateway}}\) is the fixed cost associated with each transmission event from aggregation points.

The total transmission cost can be calculated as:

$$\begin{aligned} C_{\text {trn}} = C_{\text {trn, gateway}} + C_{\text {trn, rc}} \end{aligned}$$
(20)

The propagation cost, \(Cost_{p}\), is determined based on the distances involved and is expressed as:

$$\begin{aligned} C_{\text {prop}} = \sum _{i=1}^{n} \left( C_{\text {dis, dev}} \cdot Dis_{i,\text {gateway}} + C_{\text {dis, gateway}} \cdot Dis_{\text {gateway},\text {rc}} \right) \end{aligned}$$
(21)

In this equation, \(C_{\text {dis, dev}}\) is the cost per unit of distance for IOMT device-to-aggregation point transmission, while \(Dis_{i,\text {gateway}}\) is the distance from IOMT device \(i\) to the aggregation point. \(C_{\text {dis, gateway}}\) signifies the cost per unit of distance for aggregation-to-regional computing transmission, with \(Dis_{\text {gateway},\text {rc}}\) representing the distance involved in this stage.

The processing cost \(Cost_{pr}\) is computed as:

$$\begin{aligned} C_{\text {prc}} = \sum _{i=1}^{n} \sum _{j=1}^{m} \left( C_{\text {uprc}} \cdot T_{\text {prc}_{i,j}} \right) \end{aligned}$$
(22)

here, \(T_{\text {prc}_{i,j}}\) denotes the processing time for data from IOMT device \(i\) and workload \(j\), and \(C_{\text {uprc}}\) signifies the processing time cost per unit.

This comprehensive cost model encompasses the expenses associated with transmitting data from IOMT devices to gateway and then to the regional computing servers, as well as the propagation and processing costs involved in handling HBD.

The cost model equations demonstrate the significant influence of distance on transmission and propagation costs, along with processing time on overall expenses (as illustrated in Eqs. 18, 19, and 22). Due to the increased distances involved in data transmission, cloud computing generally incurs higher costs. In contrast, regional computing optimizes costs by minimizing transmission distances and enhancing processing efficiencies, rendering it a more cost-effective approach for managing HBD.

Algorithm

The Algorithm 1 is designed to handle the large-scale data generated by IOMT devices, including wearables, medical imaging systems, remote monitoring, and emergency response systems. The data generated from these sources \(D = \{d_{1}, d_{2}, d_{3}, \ldots , d_{n}\}\), and their associated workloads \(w = \{w_{1}, w_{2}, w_{3}, \ldots , w_{m}\}\), are processed through a tiered system, which leverages Edge Computing (EC) (Gateway) for immediate, real-time needs, RC for intermediate tasks, and Cloud Computing (CC) for intensive processing.

Algorithm 1
figure a

IoMT big data processing and offloading.

The IOMT algorithm functions by efficiently distributing data processing across multiple layers (Edge, Regional, and Cloud Computing) based on the needs of the healthcare applications and the current network conditions. Initially, as shown in Fig. 5, data generated by IOMT devices, such as wearables or emergency systems, is checked to determine if it requires immediate processing. If the data is time-sensitive and gateway resources are available, the algorithm processes it locally. This ensures minimal delay and provides real-time analytics, which is essential for critical healthcare applications like patient monitoring or urgent diagnoses.

Fig. 5
figure 5

Flowchart for healthcare big data.

When network utilization is high and edge resources are insufficient, the algorithm considers offloading the data to RC. If the regional servers have available capacity, the data is processed at this intermediate layer. This step helps in balancing resource utilization while minimizing the dependency on external cloud services.

In situations where neither EC nor RC is viable, or if the data processing tasks are particularly resource-intensive, such as those involving medical imaging analysis, the algorithm shifts the workload to Cloud Computing. This ensures that more computationally demanding tasks are handled efficiently, even if it increases the dependency on centralized cloud resources. For critical or urgent medical tasks where real-time data analysis or rapid migration to other regions is necessary, the algorithm gives priority to cloud processing. Additionally, it supports the migration of critical data to other regions for immediate analysis and decision-making. By following this tiered processing approach, the algorithm ensures that HBD is managed efficiently, providing real-time patient care while balancing network traffic and optimizing resource allocation. This structure helps healthcare systems address the growing demands of data-intensive medical applications, ensuring timely insights and interventions.

Evaluation

To evaluate the proposed methodology, we conducted experiments using two types of setups: an Arduino prototype for network performance and the EdgeCloudSim simulator for data center-related parameters. In the first setup, an Arduino R4 WiFi board was used to connect various Internet of Medical Devices (IoMT), including a pulse sensor, heartbeat sensor, pulse oximeter, heart rate monitor, blood oxygen concentration sensor, and temperature sensor, simulating real-world data transmission scenarios. Due to limitations in device availability, we virtually multiplexed the number of connected devices from 10 to 2000, replicating real-time network behavior. In parallel, we utilized EdgeCloudSim66 to simulate the data center environment, focusing on resource utilization and network error rates. This dual approach allowed for a comprehensive evaluation of the methodology, considering both network and data center performance.

Experimental setup

A set of Internet of Medical Devices (IoMT) were connected to an Arduino R4 WiFi board, enabling the communication of sensor data over the network. These sensors provided continuous real-time data, which the Arduino captured and transmitted to a remote system for processing.

Since the Arduino board and the connected devices were limited in terms of the number of devices they could handle, we employed a method to virtually scale the device network. By multiplying the sensor data from the initial set of devices by a factor of n, we were able to simulate up to 2000 devices, with each device transmitting 1000 KB of data.

Key parameters, as shown in Table 1, included an initial device count of 10, which was incremented by 10 per iteration up to a maximum of 2000 devices, each transmitting data at an initial bandwidth of 5000 KB/s. To simulate realistic conditions, we used one cloud server, one regional server, and one edge server, with a network topology incorporating Wireless, LAN, and WAN connections. The energy cost per millisecond was set to 0.001, network transmission cost to 0.005 per KB, and cloud processing cost to 0.001 per ms. Simulation scenarios were repeated 10 times over a 30-min duration, measuring round-trip delay and computing the total communication and processing costs for analysis. This configuration enabled a thorough assessment of system performance under varying load and network conditions.

Table 1 Experimentation parameters setting.

The experimental setup was divided into two categories for detailed analysis:

  1. 1.

    In the first scenario, a prototype using Arduino R4 WiFi was developed to collect sensor data and transmit it to both cloud and regional computing systems, enabling observation of network behavior.

  2. 2.

    In the second scenario, a simulation environment was created on EdgeCloudSim to observe data center behavior in managing healthcare big data.

The remaining section covers these experimantation and simulation in detail.

Arduino R4 Wifi

In the prototype, we incrementally increased the number of devices from 10 to 2000, leading to a proportional rise in communication cost. As illustrated in Fig. 6, the communication cost for cloud computing escalated significantly, rising from 0.5 to 100 $ as the device count increased. This sharp rise is due to the longer distances and larger data volumes involved in transmitting data to centralized cloud servers. Conversely, regional computing exhibited a steadier increase, with communication costs rising from 0.1 to only 30 $, maintaining a relatively stable rate compared to cloud computing. This reflects regional computing’s efficiency in scenarios with lower data transmission requirements.

Fig. 6
figure 6

Comparison of communication cost.

The processing cost increases with the number of devices as more data requires additional computational resources. However, as shown in Fig. 7, the rate of increase for cloud computing is significantly steeper, with processing costs rising from 4.6 to 928.3 $ as device count increases from 10 to 2000. This steep increase is due to the higher computational expenses incurred by centralized cloud servers as the workload scales. In contrast, regional computing demonstrates a more gradual rise, with processing costs increasing from 2.3 to only 463.6 $, benefiting from localized processing that maintains a more stable and lower processing cost, even as devices and data grow.

Fig. 7
figure 7

Comparison of processing cost.

As observed in Fig. 8, the throughput in cloud computing initially increases rapidly with the addition of devices, peaking at 5000 KB per second when handling around 1000 devices. However, as device numbers continue to grow, throughput begins to decline, dropping to 3333 KB per second at 2000 devices due to system overload from the massive workload. In contrast, regional computing maintains a stable throughput throughout, as it distributes the workload more evenly. This consistent resource usage in regional computing allows it to handle the regional workload loads without the performance degradation seen in cloud computing.

Fig. 8
figure 8

Comparison of throughput.

As shown in Fig. 9, congestion in cloud computing escalates sharply as the number of devices grows, with congestion levels reaching 75% at 800 devices and nearing 600% at 2000 devices. This increase in congestion results in significant network bottlenecks and degraded performance due to the high data transmission volume, which strains the cloud infrastructure. In contrast, regional computing maintains a consistently. It easily supports 1000 devices. This stability in regional computing is due to its localized data handling (limited devices), allowing it to efficiently manage the workload and avoid the severe congestion issues seen in cloud computing.

Fig. 9
figure 9

Comparison of congestion.

As shown in Fig. 10, cloud computing experiences a significantly higher average network delay of approximately 363 ms. This delay is primarily due to the long-distance data transfer to centralized cloud servers, which is further exacerbated by increased traffic and workload, leading to higher latency. In contrast, regional computing maintains a much lower and more stable average delay of around 163 ms, even as the number of devices increases. The lower delay in regional computing is attributed to the localized processing, which minimizes data transfer distances and avoids the bottlenecks commonly encountered in cloud computing, resulting in consistently faster data transfer times.

Fig. 10
figure 10

Comparison of network delay.

EdgeCloudSim

Figure 11 displays the server utilization metrics for both cloud and regional computing environments. Cloud server utilization shows slight fluctuations between 0.958 and 1.081 as the task load increases. In contrast, regional server utilization starts at 8.8877 for 119,357 tasks and increases to 29.2775 as the load reaches 257,252 tasks. Despite the higher utilization percentages observed in regional computing, it maintains optimal performance, demonstrating its resilience and effective resource allocation. The increased utilization in regional computing reflects its ability to scale efficiently without compromising performance.

Fig. 11
figure 11

Comparison server utilization.

Figure 12 illustrates the average processing time comparisons between cloud and regional computing environments. Cloud computing shows relatively stable processing times, ranging from 0.0733 to 0.0786 s as the number of tasks increases. In contrast, regional computing experiences significantly longer processing times, starting at 1.6110 s for 119,357 tasks and rising to 2.5716 s for 257,252 tasks. Despite the higher processing times in regional computing, this increase is gradual, reflecting its capacity to handle tasks efficiently at the regional level while maintaining a steady performance.

Fig. 12
figure 12

Comparison of processing time.

Figure 13 illustrates the comparison of failed tasks between cloud and regional computing environments. In cloud computing, the number of failed tasks is significantly higher, with failure rates ranging from 87.09% in iteration 1 to 91.74% in iteration 5. This higher failure rate is attributed to the larger network delay in cloud computing, which impacts task completion and results in a greater number of failures as the task load increases. In contrast, regional computing maintains a much lower failure rate, ranging from 0.81% in iteration 1 to 1.25% in iteration 10. This lower failure rate highlights regional computing’s ability to handle tasks more efficiently, with reduced delays and better task completion rates even as the task load increases.

Fig. 13
figure 13

Comparison of failed task.

Discussion

This section presents a comparative analysis of cloud computing and regional computing across multiple performance metrics, including communication cost, processing cost, throughput, congestion, network delay, server utilization, processing time, and task failure rates, as illustrated in Figs. 6, 7, 8, 9, 10, 11, 12 and 13.

The analysis reveals that communication costs in cloud computing increase sharply as the number of devices and data volume rise. This trend can be attributed to the extended distances data must travel to reach centralized cloud servers, which incurs significant transmission costs under high loads. In contrast, regional computing demonstrates a more stable communication cost pattern. Due to localized data processing, the transmission distance and hence the associated cost remains lower, making regional computing a scalable and cost-efficient solution, especially in scenarios involving a large number of connected devices.

Processing costs in cloud computing also rise steeply with the growth in devices and data, as seen in Fig. 7. The centralized nature of cloud computing necessitates higher resource allocation on central servers, which translates to higher computational expenses under increasing workloads. Regional computing, however, manages processing costs more effectively by leveraging localized resources. This decentralized approach enables a more stable cost structure, showcasing regional computing as a cost effective choice for environments with heavy processing requirements.

Regarding throughput, cloud computing initially demonstrates high performance as more devices are added, but this increase plateaus and eventually declines when system capacity is reached, leading to performance bottlenecks. Regional computing, on the other hand, maintains a consistent throughput throughout the workload increments. By distributing tasks across regional servers, regional computing avoids the extreme resource saturation seen in cloud infrastructure, enabling it to handle increased demands without substantial performance degradation.

Cloud computing experiences substantial congestion as device numbers increase, with data flow encountering network bottlenecks that degrade overall system efficiency, as displayed in Fig. 9. This congestion arises from the need to transmit large volumes of data over extended distances. Conversely, regional computing maintains low and stable congestion levels by processing data closer to the source, allowing it to better manage high workloads without experiencing severe congestion, thus providing more efficient data transmission.

Network delay in cloud computing escalates with device count, primarily due to the longer transmission distances to centralized cloud servers, exacerbated by increased traffic on the cloud infrastructure. Regional computing mitigates these latency issues by localizing data processing, resulting in consistently lower and stable network delays even as device numbers rise. The minimized distance and reduced potential for bottlenecks contribute to more reliable data transfer times in regional environments.

In terms of server utilization, regional computing shows steady and efficient resource usage, adapting to increasing tasks without compromising performance. The utilization rate in regional computing rises predictably, as shown in Fig. 11, indicating effective resource allocation. Cloud computing, however, shows minor fluctuations in utilization, suggesting less efficient handling of resources as workload demands grow, which can hinder scalability in intensive environments.

Although cloud computing achieves faster processing times, regional computing provides more stable processing durations as tasks increase. In Fig. 12, regional computing exhibits a gradual rise in processing time, but this increase remains controlled compared to cloud computing. While cloud processing may seem advantageous in speed, regional computing’s consistent handling of tasks and reduced latency make it better suited for sustainable and reliable performance at scale.

A critical area where regional computing excels is in task failure rates. Cloud computing encounters a high task failure rate as network delays and resource allocation challenges increase with the workload. Conversely, regional computing maintains a low task failure rate, as shown in Fig. 13. This lower rate indicates effective resource allocation and superior task management, making regional computing more reliable in maintaining task completion under heavy load.

In summary, while cloud computing remains a powerful solution for large-scale processing, it encounters issues such as increasing costs, network congestion, and higher latency as data and device volumes rise. Regional computing offers a viable alternative by providing lower communication and processing costs, stable throughput, efficient resource utilization, and reduced delays. Despite slightly longer individual processing times, regional computing’s advantages in scalability and performance make it especially suitable for edge and localized applications, where cost efficiency and reliability are paramount.

Conclusion

Cloud computing, while effective for large-scale data handling, presents notable limitations in the context of healthcare big data. The centralized nature of cloud infrastructure leads to high latency, network congestion, and costly data transmission, all of which impede the timely processing required for real-time healthcare applications like continuous patient monitoring and robotic surgery. These delays in data analysis can hinder quick decision-making, impacting patient outcomes and the overall efficiency of healthcare delivery. To address these issues, this study proposes a regional computing (RC) approach, designed to alleviate the dependency on cloud systems by incorporating strategically positioned regional servers. This RC framework processes and stores data closer to the source, reducing transmission distances and mitigating congestion, thus providing a more responsive, scalable solution for handling healthcare big data. Experimental results reinforce the advantages of RC, showing reduced communication costs, more stable throughput, lower congestion, and minimized network delays compared to cloud computing. By delivering timely data insights at a regional level, RC empowers healthcare professionals with the data-driven insights necessary to optimize treatment strategies, improve diagnostics, and enhance patient monitoring in real time. This decentralized approach effectively meets the demands of modern healthcare, ensuring data is processed efficiently and accessibly, ultimately supporting more personalized and responsive care. The proposed system demonstrated effective performance; however, challenges remain in optimizing data offloading decisions. As part of future work, we plan to integrate Artificial Intelligence and Fuzzy Logic Systems to enhance the efficiency of data offloading to edge, regional, and cloud computing environments. This approach aims to achieve optimal cost, reduced delay, and better handling of computational demands.