Sage Journals: Discover world-class research

Abstract

Internet of Medical Things (IoMT) systems are envisioned to provide high-quality healthcare services to patients in the comfort of their home, utilizing cutting-edge Internet of Things (IoT) technologies and medical sensors. Patient comfort and willingness to participate in such efforts is a prominent factor for their adoption. As IoT technology has provided solutions for all technical issues, patient concerns are those that seem to restrict their wider adoption. To enhance patient awareness of the system properties and enhance their willingness to adopt IoMT solutions, this paper presents a novel methodology to integrate patient concerns in the design requirements of such systems. It comprises a number of straightforward steps that an IoMT designer can follow, starting from identifying patient concerns, incorporating them in system design requirements as criticalities, proceeding to system implementation and testing, and finally, verifying that it fulfills the concerns of the patients. To showcase the effectiveness of the proposed methodology, the paper applies it in the design and implementation of a fall detection system for elderly patients remotely monitored in their homes.

Keywords

internet of medical things model-based design patient concerns remote monitoring system fall detection

Introduction

The advent of Internet of Things (IoT) has resulted in the proliferation of ambient intelligence, smart devices and novel computing technologies, envisioned to improve life quality. The particular incorporation of increasing IoT characteristics in Healthcare,¹ has led to the emergence of the Internet of Medical Things (IoMT) systems. These systems are composed of sensor-based medical devices, integrated with cutting-edge IoT technologies; their combination promises better patient health outcome, easier access to medical information, and reduced healthcare expenses.² Medical monitoring systems are indicative examples of IoMT-based systems, which enable the remote monitoring of the daily activities and medical conditions of patients in real-time. These systems facilitate a patient to lead an autonomous, high-quality life.^3,4

However, the existence of cutting-edge IoT solutions does not necessarily coincide with the successful adoption of IoMT systems by the patients. Patients, especially, become part of the IoMT system, as they often should wear or carry medical devices. As explored in Martínez-Caro et al.⁵ the capability of patients to effectively use medical devices (aka e-skills), and even more their attitude toward IoMT-based services (aka e-loyalty), primarily affect their willingness to adopt such solutions. The technological advances in the field do not seem to change their attitude. Concerns related to the convenience of the wearable device(s) in terms of size and weight, data availability and security, and ease-of-use constitute a greater determinant of patient acceptance of IoMT-based services.⁶

To this end, the patient concerns on system usage should also be identified and taken into account during system design. These concerns correspond to critical design requirements that restrict the functionality of the system. In the work presented in, Kotronis et al.⁷ we proposed a comprehensive approach to evaluate IoMT systems from a human-centric perspective. Patient and caregiver concerns were identified and transformed into associated design requirements, named criticalities.

The term criticality is associated with the severity of the consequences to the human user, should a system component or a provided service fail. The term was extended to include “soft” properties, like privacy and ease-of-use, crucial for patients, named human criticality. Human criticalities were analyzed in order to evaluate the capability of IoMT systems to fulfill them. This resulted in the identification of ways to further improve such systems.

In the light of the above, the challenge still remaining is to design an IoMT system taking human criticalities into account from the start. Such a system would contain patients’ and caregivers’ concerns, as identified in, Kotronis et al.⁷ and enhance their e-loyalty, as defined in, Martínez-Caro et al.⁵ while coping with their e-skills, described as human restrictions, in an effort to promote their willingness to adopt IoMT systems.

In this paper, we put into effect the human concerns and criticalities identified in, Kotronis et al.⁷ and introduce a comprehensive model-based design methodology incorporating human criticalities as design requirements, that the IoMT system should satisfy, emphasizing patient concerns. Wearing medical devices results in making patients part of the IoMT system, thus their willingness to properly use their devices directly reflects on the operation of the system. Thus, they should become the focus of attention. However, caregivers’ concerns should also be taken into account, since IoT devices such as smartphones should also be used by them to monitor patient health remotely and intervene when appropriate. In the following we focus on patient concerns, though the same methodology could be applied to explore caregivers’ concerns as well. Testing the system implementation against patients’ concerns is also incorporated into the proposed methodology, to enable IoMT system designers to select and configure medical devices based on these concerns. The methodology consists of the following steps that an IoMT designer can follow in a straightforward fashion.

It enables the interaction with patients to depict their concerns in a simple, yet straightforward, semi-quantitative fashion.

It facilitates the concerns’ transformation into quantitative design requirements associated to IoMT system components.

It provides the effective design and configuration of the system.

It verifies the satisfaction of patient concerns regarding specific system implementations and configurations.

The proposed methodology is employed for the design and implementation of a fall detection system; this is an indicative IoMT system, since patients, that is, usually elderly individuals, wear medical sensors and deploy monitoring IoT devices to remotely monitor their medical condition while at home.⁸

The paper is structured as follows: a short overview of state-of-the-art IoMT applications is presented in section 2. In section 3, the proposed methodology is described in detail. In section 4, its application in a fall detection system implementation is discussed. Corresponding results are provided in section 5, while concluding remarks are drawn in section 6.

Research background

The rapid breakthrough of IoMT technologies has drawn the attention of researchers in the direction of intelligent and efficient design for healthcare. The common scope of these advances is that they seamlessly connect sensors and devices to improve information delivery and the care-giving process in healthcare services.⁹ A prominent example of such systems, increasing the level of independence of the patient, is the Remote Health Monitoring System. Such a system provides remote monitoring and diagnosis for the sensitive demographic subjects, dealing with the real-time diagnosis of medical incidents. Wearable sensors collect the medical information of patients and transmit them to healthcare professionals for further assessment and recommendations^7,10,11

The implementation of innovative sensing technologies such as wearable or implantable force sensors,¹² or flexible e-skin pressure sensors¹³ for monitoring human physiological signs provide the infrastructure to build appealing IoMT applications. Low cost and easily implementable IoT based health monitoring systems that offer accurate measurement of heart rate, blood pressure, glucose level and other health parameters of patients are also proposed in, Moghadas et al.¹⁴ and Savaridass et al.¹⁵ Increasing demands of current IoMT-driven applications require leveraged solutions for effective health monitoring, decision making and data storage.¹⁶

In such a context, the highly dynamic and real-time nature of IoMT systems can be enhanced by AI-based methods which can endow IoMT systems with several degrees of intelligence¹⁷ in decision making and provide a higher degree of robustness and accessibility.¹⁸ Moreover, the advantages of AI-driven innovation can extend the boundaries of healthcare outside of hospital settings by transforming the hospital-centric to patient-centric ecosystem.¹⁶ A wide range of AI approaches can be effectively adopted for the IoMT concept, as discussed in, Fouad et al.¹⁹, Mohan et al.²⁰ and Kumar et al.²¹ in order to enhance decision making, anomaly detection, predictive risk monitoring, treatment support and so on.

All above efforts have contributed significant functional features to create more efficient IoMT systems from a technical point of view. As the adoption of IoMT systems is strongly related to the willingness of patients to employ and use medical devices,²² it is essential for such systems to ensure that patients are the focal point of all healthcare solutions, in order to achieve patient satisfaction and a greater adoption. To this end, recent studies have explored the involvement of the humans to healthcare systems. In Wesley et al.²³ both patient and healthcare caregiver perceived facilitators were explored for successfully implementing healthcare applications. Specifically, a number of factors such as usability, flexibility, privacy and data availability were identified as critical barriers to the applications’ adoption. Human concerns have also been identified in Muzny et al.²⁴ for the integration of wearable health devices; convenience and possible functionalities were concerns essential to patients, while healthcare providers valued data reliability, device certification, and data transmission risks. The importance of convenience and usability of wearable devices for the elderly have been also recognized in Kekade et al.²⁵ and Talukder et al.²⁶

Patients are part of the IoMT system, as they often should wear or carry medical devices. As explored in, Martínez-Caro et al.⁵ the capability of patients to effectively use medical devices (aka e-skills), and even more their attitude toward IoMT-based services (aka e-loyalty), primarily affect their willingness to adopt such solutions. While there are works that attempt to explore the willingness of patient to adopt such services and identify their concerns after system implementation,^7,24 none of them indicates an effort to take patients’ concerns into consideration while designing and implementing an IoMT-based service. In addition, there is not a comprehensive methodology that takes into account the activities of patients and their active role in IoMT systems success. To fill that gap, we propose a model-based methodology for the effective design and implementation of IoMT systems taking the preferences, that is, the concerns and derived criticalities of patients into account for the design, implementation and testing of such systems. Such concerns may focus on the proper operation of the system, as well as privacy, cost and comfort.⁷

Methodology

The concept of the human criticality was introduced by the authors⁷ in order to depict human concerns. In the case of IoMT systems, the concerns that a patient or a caregiver has, indicate restrictions or specifications regarding humans themselves (e.g. e-skills) or their expectation of the system (e.g. provided comfort or affordability). Different criticality types were also introduced. In the following, we introduce a comprehensive model-based design methodology, incorporating human criticalities as design requirements, to design, implement, and test an IoMT system. Testing the system implementation against human criticalities is an important feature, enabling the IoMT designer to demonstrate to patients that their concerns have been taken into account during the configuration of the system, enhancing their willingness to use it. The basic concepts, used to model human criticalities that are related to design requirements and are associated with IoMT system components, are shown in Figure 1. Human criticalities are described by the patients or the caregivers in a textual form. In addition, they are assigned a criticality level that is described in a graded fashion (e.g. “low,” “medium,” “high”), representing levels of user satisfaction; these levels are redefined by the IoMT designer. Each criticality level is captured by a levels property. Different types of criticalities, introduced in the work of, Kotronis et al.⁷ are also depicted in Figure 1. Although in, Kotronis et al.⁷ privacy of the medical data was included within the Data Preservation criticality type, privacy is treated as a separate criticality type, referring to the restriction of the ownership, management, and transmission of the medical data between the components within the system, as medical data are extremely sensitive according to recent legislation applied in Europe (GDPR).²⁷ Human criticalities are associated to corresponding IoMT system components by patients; these components should satisfy the criticalities. The IoMT designer is responsible for defining all the properties of the components, prescribing their functionality, and translating criticalities into design requirements, using Criticality verification formulas. In turn, these criticalities are associated to the components’ properties. This way, the designer specializes the human criticalities, defined by patients, into specific requirements where a system configuration can be tested against. In order to facilitate this, the Verification Data is used, extracted by the actual IoMT system and included within the system design model.

Figure 1.

Basic IoMT system design concepts.

The methodology enables an IoMT system designer to follow specific steps, as depicted in Figure 2; these steps are described in the following.

Figure 2.

A model-based design methodology for IoMT systems incorporating patient concerns.

Step I. Define system structure and human criticalities

Using the design model, the IoMT designer defines basic system components, described by structural properties whose values can be set during later steps. For example, an IoMT system comprises various medical sensor devices that hold properties such as size, battery consumption, etc. Note that there may be composite components, comprising others and forming the hierarchy of the structure of the system.

Having the system components at hand, the designer may include human criticalities, as prescribed by the patient. For example, the patient of an IoMT system may require “low price” as an affordability criticality.

Furthermore, the designer defines design requirements, describing criticality verification formulas that are refined by patient criticalities, and associates them to IoMT system component properties; these requirements can be verified at a later step (v).

Step II. Configure the system

In order to further enhance the design process, the designer provides value ranges for all IoMT system component properties. These values represent alternative configuration sets of the real IoMT system. Different combinations of the values represent different configurations of the system; these combinations are tested in step (iv).

Step III. Implement real system

Based on the system model, the real system can be configured; note that its basic components can be manufactured or purchased.

Step IV. Test system implementation

System implementation tests may be conducted on both hardware and software, leading to the validation of the hardware devices and software applications of the implemented system. Specifically, during system testing, the list of values, created in the configuration step (step ii), is employed. Different combinations of values for each component are tested in real-world scenarios, achieving different output metrics (e.g. real-time execution requires minimal processing time). The values with the most favorable metrics are candidates for further criticality verification (see final step).

Step V. Instantiate system model and criticality verification data

In this step, the system components are populated with a specific set of values, chosen during system testing; at this point specified instances of the system are being modeled. The values of the components’ properties are in turn used as input to criticality verification formulas; the computation of these formulas generates the real criticality level of the human concerns. The latter value is stored within a corresponding criticality verification data element; this element serves two purposes: it hosts the computed level and compares it against the one desired by the user, leading to the final criticality verification outcome.

Step VI. Verify human criticalities

To verify human criticalities, their desired levels are compared to the computed levels. In case the respective criticality is not verified, the system cannot meet the patient concern.

The methodology can be iterated according to the preferences of the designer, starting from the system structure, implementing the system and ending with its verification against the patient concerns. Thus, the designer is enabled to reconsider the system structure or the related criticalities and their levels (i.e. setting a lower level), re-configure the system in case they are not verified, or run another testing scenario and instantiate different design alternatives—in coordination with the patient—, resulting to a better solution for the system design. When this solution is reached, the IoMT system may be purchased by the patient, who in turn will have everything at hand to commence the respective healthcare process.

Case study: Implementing a fall detection system

We demonstrate the feasibility and applicability of the proposed model-based methodology in the design of a fall detection IoMT-based system, where elderly patients reside and may operate appropriate medical equipment in the comfort of their home; we focus on the fall detection case, where the position and stance (sitting, lying, etc.) of elderly individuals should be recorded and monitored via specific medical sensor device(s). Should a patient fall, the system alerts remote healthcare providers to act.

In an example Home scenario, a post-surgery elderly patient with heart failure can live independently at his residence and recover, although frequent monitoring of his position and stance (sitting, standing, falling) is mandatory. For this purpose, an IoMT-based system was designed and implemented by Hamad Medical Corporation and the College of Engineering at Doha University as part of EMBIoT project,²⁸ in Qatar. The system installed at patients’ homes consists of the following components: (a) a fall detection sensor, suitable for recording the position and acceleration of the patient’s body and (b) a data aggregator that is used to collect sensor-generated data and transmit it to a remote healthcare facility (e.g. a hospital) for monitoring and assessment. After acquiring these devices, the patient can start the monitoring process and receive remote healthcare services.

The application of the proposed methodology had two purposes: (a) to enable the researchers in the College of Engineering at Doha University to provide an implementation of the system that matches patient concerns and test its performance accordingly and (b) to assist the IoMT system designers employed in Hamad Medical Corporation, to configure an acceptable solution, properly initializing EMBIoT equipment for patients, taking into account their specific concerns.

The overall process is depicted in Figure 3. Note that each step as well as the frame of the elements that are associated to this step have the same distinct color, while steps are shown in the legend of the figure.

Figure 3.

Model-based methodology applied to Home fall-detection scenario.

Define system structure and human criticalities

The Hamad Medical Corporation in collaboration with the College of Engineering, Doha University, decided to employ the Shimmer3-IMU²⁹ as the medical sensor device that the patient wears for the detection of occurrence and severity of sudden falls. The Odroid-XU4³⁰ was the data aggregator chosen to collect all sensor-generated data and transmit it to the remote healthcare facility. Both devices were employed in similar applications, however they should be tested and properly configured to satisfy fall detection requirements.

A two-layer model represents the patient home, ElderlyPatientHome composed of the device(s) and the aggregator, forming a structural hierarchy (see black shapes in Figure 3). Each component holds specific properties, describing it. They are defined in the next step.

System components are associated to human criticalities, representing patient concerns, often in conflict to each other. They are described in a textual form and graded in levels, to be easily described by patients. Indicatively, in Figure 3, two conflicting patient concerns are explored. The first one, MonitoringInRealTime, is of monitoring type and depicts the need to realize possible fall with no delay. It is graded in three levels: “real time,” “best effort,” and “non important.” Depending on the patient condition, a small delay (e.g. up to one minute) could be tolerable, thus “best effort” may be selected. This concern is related to IoMT system as a whole, thus is associated to the Home layer. The second criticality is SWaP (i.e. Size, Weight and Power) of comfort type that restricts the size and energy consumption of the wearable device, in this case Shimmer3. Comfortable wearables lead to a greater willingness to adopt and use a remote monitoring system. Monitoring concerns automatically generate (indicated as arrows in Figure 3) Time restrictions associated to all system components. In practice, they indicate the time frame that all the system components should operate in. Regarding Time criticalities, the Elderly Patient Home is connected to the Real Time Transmission criticality that describes the requirement of all components to communicate in real-time. The Odroid Aggregator is associated with the Real Time Aggregator Operation describing that real-time collection and processing of sensor data is required in order to decide whether the patient has fallen. The Shimmer Device satisfies the Real Time Device Operation criticality that points out the need for real-time generation and transmission of fall detection data. All these requirements are described in a qualitative fashion using graded levels, by the patient with the assistance of IoMT system designer. They are further analyzed in a quantitative fashion by the system designer with the assistance of the system constructor (e.g. Doha University researchers) in Step V (blue-colored shapes is Figure 3).

Configure the home IoMT system

Fall detection system designer identifies system component properties, relevant to system design (e.g. those that their values reflect on the setup of the system) and constructs values lists in collaboration with the system constructor. For example the Odroid data aggregator property value list is depicted in Figure 3, as an orange-color-framed rectangle (Step II of the methodology). According to this list, the core type property of the Odroid aggregator may obtain the “A7” (i.e. low-powered, medium-performance CPU core) or the “A15” (i.e. high-power, maximum-performance CPU core).

These values are restricted by the device characteristics, as for example for core type property, while they may also be restricted by the system constructor implementation decisions, as for example for reconstruction algorithm property. As described in Djelouat et al.³¹ the reconstruction algorithm of the compressed signal received by the sensor plays an important role on the aggregator performance when deciding when a fall occurred or not. In this case two well-known greedy algorithms, the orthogonal matching pursuit (OMP)³² and subspace pursuit (SP)³³ were selected for reconstructing the compressed acceleration data. Greedy algorithms are widely considered for real-world applications as they exhibit a simple implementation architecture, a fast convergence to the solution and a sub-optimal recovery.

Implement and test real system

Following its design, the actual system is composed, as depicted in Figure 3 with a green-colored frame. The system constructor is now aware of all the properties of the system that affect design decisions. These properties are defined in Step II. Thus, the constructor may test the behavior of the actual system in a controlled environment, to explore how these properties affect each other and the graded levels of related criticalities, with the collaboration of the system designer. Different sampling rates may be used in the sensor to identify the position of the body, while data is compressed to be transmitted to Odroid-X14 aggregator, where the signal is recovered and based on training samples, the aggregator decides whether a fall may have occurred. Implementation details are provided in Djelouat et al.³¹ One of the primary performance metric explored while testing the operation of Odroid-X14 aggregator was the execution time needed to make a decision on whether a fall occurred. The execution time metric is directly related to the estimation of real time operation criticality level for the aggregator and is related to all the properties of the aggregator, identified in Step II (see the orange-colored frame is Figure 3). As agreed between Hamad Medical Corporation (system designer) and Doha University (system constructor), execution time less than 0.02 s ensures real time operation (real time level of the RealTimeAggregatorOperation criticality). The core type, number of cores, core frequency and data reconstruction algorithm affect execution time. Thus, different combinations of their values should be explored during testing. Testing results are presented in Figures 4 and 5, indicating the execution time using “A7” cores and “A15” cores, respectively. The execution time has been estimated for different combinations, and based on that, the three RealTimeAggregatorOperation criticality levels, namely “real-time” (execution time less than 0.02 s), “best-effort” (execution time less than 0.2 s) and “non-important” are extracted. One should note that the “A7” core may not perform in real time. The “A15” may perform in real time using more that two cores in any frequency when SP reconstruction algorithm is used, while using OMP this may be performed using more than 1.2 GHz frequency.

Figure 4.

Execution time using the “A7” cores based on number of cores and operating frequency.

Figure 5.

Execution time using the “A15” cores based on number of cores and operating frequency.

Testing the actual system against patient criticality requirements prior to its installation, eliminates system configurations that do not quarantee the efficient operation of the system. This enables the system constructor to provide solution that may be more acceptable by patients, since the system is configured and tested taking patient concerns into account as well.

Instantiate system model and criticality verification data

In this step, the blue-color-framed blocks, shown in Figure 3, representing instantiated system elements, obtain specific values after system testing. For example, the Shimmer device holds distinct values regarding size or data generation and transmission properties (e.g. $r e c o n s t r u c t i o n a c c u r a c y = H i g h Q u a l i t y (H Q) "$ ) (see Figure 3).

According to our methodology, each defined human criticality, representing patient concerns, is associated with a respective verification criticality formula, describing criticalities in a quantitative fashion, and a verification data entity, containing data extracted by the actual system testing to verify the criticalities. For example, the Real Time Aggregator Operation criticality is linked to the Real Time Aggregator Operation Verification formula and is verified using data stored in VRD Real Time Aggregator Operation verification data associated with Odroid-XU4 aggregator (see Figure 3). These are also represented as blue-color-framed blocks in Figure 3.

The Real Time Aggregator Operation Verification formula is constructed by the system designer to calculate Real Time Aggregator Operation criticality level. The formulas provide a quantitative description of the human criticality, associating Odroid-XU4 properties based on the results of system testing provided by system constructor. Real Time Aggregator Operation Verification formula is based on the data presented in Figures 4 and 5. The criticality computation results in “real-time” level value, based on the values of Odroid-XU4 properties, which are retrieved by the actual system, and is stored in the VRD Real Time Aggregator Operation verification data entity.

Verify patient criticalities

In Figure 3, the Device Battery Lifetime human criticality, representing comfort patient concern, is not verified by the proposed configuration. Thus, it is annotated by red color. The desired criticality level is set as “occasionally,” indicating the patient’s preference to charge the device once in a while. The related verification data element holds the computed level value and is estimated as “frequently”, indicating the need to charge the device frequently. This is reasonable, since the Shimmer device should be operating in real-time, consuming the battery. When these two values are compared, the criticality is not verified. In addition, the verification data and the connection between the criticality and the component are also annotated, depicting that the instantiated component cannot satisfy its criticality. The monitoring patient concern, represented as Monitoring Real Time human criticality, which is related to the whole system, is in fact satisfied, thus not annotated.

It is worth mentioning that in case there is an inconsistency (annotated criticality), the modeling environment alerts the system designer, exhibiting appropriate information. The patient may be informed that not all concerns can be satisfied by the available system configurations and decide with the assistance of the system designer which of them should be relaxed. In this case, real time monitoring needs frequently battery charging.

Results and discussion

Although patient’s concerns may be recorded as part of the system requirements, aka criticalities, (Steps I and II of the proposed methodology), the tricky part is to find a way to associate them with the characteristics (structural and behavioral) of the system implementation (Steps III and IV). The criticality verification formulas defined by the system designer (Step V) relay on the combination of specific system properties and the system behavior under different conditions. The latter may only be obtained as the result of complex system testing. Thus, the system designer may only obtain this information in collaboration with the system constructor.

In most cases, system constructors study their system behavior (for example system performance, security or energy consumption) under different conditions and provide metrics important to them, not directly linked to patient concerns. The system designer should be able to relate these metrics to specific patient concerns depicted in an abstract manner, as criticality levels. To do this, system designers construct criticality verification formulas. However, they are restricted to the metrics available by the system constructors. If the patient concerns are incorporated in the system requirements, even in an abstract, graded fashion, the system constructor may take them into account, while testing the system, and, thus, provide the system designer all the necessary metrics.

Take the MonitoringRealTime criticality for example. The patient needs to be monitored in real-time. No delays, however small, are tolerable. The question the system designer has to solve is under which conditions this might be possible. Thus, the designer associates restrictions to all the devices operating in the patient’s home. For example, the RealTimeAggregatorOperation criticality imposed to Odroid data aggregator component, indicating that it should detect possible fall detection in real-time. However, this requirement may mean little to the system constructor. How fast is real-time? Thus, time limitations should be explored during system testing. Although the designer may realize that the verification of RealTimeAggregatorOperation criticality may relay on the combination of the aggregator’s properties, the actual result may not be determined unless the real system is tested combining these properties to determine the execution time. Having this in mind, the Qatar University team tested the Odroid-XU4 component, using several combinations of processors, number of cores, their respective frequencies and reconstruction algorithms. The corresponding results are presented in Figures 4 and 5, assessed by averaging the experiment over “100” trails.

The following observation can be deduced from the obtained results. (i) The “A15” outperform the “A7” cores regardless of the frequency and number of cores used. (ii) For the “A7” cores, the core frequency does not play an important role in the acceleration of the computation process. In fact, the number of cores govern entirely the performance in terms of execution time. (iii) The “A15” cores exhibit a faster performance. Moreover, both “SP” and “OMP” algorithm respond well to the increase of frequency and the number of cores. In general, for a particular CPU (core) frequency, when the number of cores is doubled, the execution time is halved. For instance, using “0.4” GHz and doubling the number of “A15” cores (“1” → “2” → “4”) reduces the execution time (“0.17” s → “0.119” s → “0.088” s) and (“0.97” s → “0.68” s → “0.061” s) for “OMP” and “SP,” respectively. (iv) Regardless of the number, type and operating frequency of cores, the processing time is always below the real-time window of “2” s. Therefore, more analysis can be further applied to the data without compromising the real-time critical metrics. Finally, it may be deducted that the optimal configuration for the data aggregator to operate in real-time, contains the “A15” core type, “4” cores and “2” GHz frequency, using the “SP” as a suitable algorithm for collected data reconstruction and compression.

Not all of this information is depicted by the system designer, when constructing the corresponding condition of the RealTimeAggregatorOperation verification formula. Designers utilize the information necessary to validate specific configuration of the system, made available to patients (see for example that not all possible frequencies are made available when instantiating the system).

Conclusion—Future work

To increase patient adoption of IoMT systems, patient awareness of the system properties should be taken into consideration. To this end, a model-based methodology was explored to integrate patient concerns as system requirements, so that possible system configurations may be tested against them. These concerns are depicted as criticalities, verified by criticality formulas, defined by system component properties and behavior metrics, obtained through system testing. Apparently there are different metrics (e.g. performance, security, energy consumption) provided by the system manufacturers/constructors. However, these metrics may not be suitable to verify a patient concern, depicted in a human criticality described using graded levels. The main aim of the proposed methodology is to provide a way to fill this gap.

Furthermore, the paper demonstrated the applicability of the methodology on the IoMT fall detection scenario. All the stakeholders involved may be benefited by the proposed methodology. Patients actively participate in the design of the IoMT system they should use and explore solution that can meet their concerns. Their active involvement may increase their willingness to use such technology. System designers may record and match patient concerns to specific system configurations. To do so, they are enabled to identify all metrics they need by the system components manufacturers/constructors to verify the system requirements, while the system manufacturers/constructors themselves have a solid knowledge on how to test their products and the metrics they should provide. Thus, they may provide all the information needed to ensure patient concerns and adopt them while improving their products, (e.g. battery life vs speed, security vs ease of use).

Several areas can be further explored in future work. The perspective of the caregivers and medical personnel will be integrated, leading to a more complete and efficient design and operation of IoMT systems. Although caregivers do not become part of the system as patients do, wearing medical devices, they play an important role in the efficient operation of such systems and their willingness to support patients this way is of equal importance.

Indicatively, leveraging the proposed methodology with caregivers concerns, we plan to explore alternative IoMT system case studies of various scales, such as a Smart Ambulance System (SAS). Furthermore, we also plan to explore the application of our methodology on case studies focusing on patient data privacy and security. In these cases, one should test regulations and procedures followed by organisations rather the operation of sensors and other IoMT products.

Footnotes

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: The authors wish to acknowledge Qatar National Research Fund project EMBIoT (Proj. No. NPRP 9-114-2-055) project, under the auspices of which the work presented in this paper has been carried out.

ORCID iD

Ioannis Routis

References

Babu

Jayashree

Prominence of IoT and cloud in health care. Int J Adv Res Comput Eng Technol 2016; 5(2): 420–424.

Joyia

Liaqat

Farooq

, et al. Internet of medical things (IoMT): applications, benefits and future challenges in healthcare domain. J Commun 2017; 12(4): 240–247.

Bujnowska-Fedak

Grata-Borkowska

Use of telemedicine-based care for the aging and elderly: promises and pitfalls. Smart Homecare Technol TeleHealth 2015; 2015: 91–105.

Mshali

Lemlouma

Moloney

, et al. A survey on health monitoring systems for health smart homes. Int J Ind Ergon 2018; 66: 26–56.

Martínez-Caro

Cegarra-Navarro

García-Pérez

, et al. Healthcare service evolution towards the internet of things: an end-user perspective. Technol Forecasting Social Change 2018; 136: 268–276.

Kim

User preference for an IoT healthcare application for lifestyle disease management. Telecommun Policy 2018; 42(4): 304–314.

Kotronis

Routis

Politi

, et al. Evaluating internet of medical things (IoMT)-based systems from a human-centric perspective. Internet Things 2019; 8: 100125.

Baig

Gholamhosseini

Smart health monitoring systems: an overview of design and modeling. J Med Syst 2013; 37(2): 9898.

Doukas

Maglogiannis

Bringing IoT and cloud computing towards pervasive healthcare. In: 2012 sixth international conference on Innovative Mobile and Internet Services in Ubiquitous Computing, Palermo, Italy, 4–6 July 2012, pp.922–926. IEEE.

10.

Kwon

Shim

Lim

Single activity sensor-based ensemble analysis for health monitoring of solitary elderly people. Expert Syst Appl 2012; 39(5): 5774–5783.

11.

Cook

Crandall

Thomas

, et al. Casas: a smart home in a box. Computer 2013; 46(7): 62–69.

12.

Cheng

Zhu

Zhang

, et al. A review of flexible force sensors for human health monitoring. J Adv Res 2020; 26: 53–68.

13.

Mahanty

Maity

Sarkar

, et al. Human skin interactive self-powered piezoelectric e-skin based on pvdf/mwcnt electrospun nanofibers for non-invasive health care monitoring. Mater Today Proc 2020; 21: 1964–1968.

14.

Moghadas

Rezazadeh

Farahbakhsh

An IoT patient monitoring based on fog computing and data mining: cardiac arrhythmia usecase. Internet Things 2020; 11: 100251.

15.

Savaridass

Ikram

Deepika

, et al. Development of smart health monitoring system using internet of things. Mater Today: Proc. Epub ahead of print 26 March 2020. DOI: 10.1016/j.matpr.2020.03.046.

16.

Farahani

Barzegari

Aliee

, et al. Towards collaborative intelligent IoT ehealth: from device to fog, and cloud. Microprocess Microsyst 2020; 72: 102938.

17.

Poniszewska-Maranda

Kaczmarek

Kryvinska

, et al. Studying usability of ai in the IoT systems/paradigm through embedding nn techniques into mobile smart service system. Computing 2019; 101(11): 1661–1685.

18.

Shinners

Aggar

Grace

, et al. Exploring healthcare professionals’ understanding and experiences of artificial intelligence technology use in the delivery of healthcare: an integrative review. Health Inf J. Epub ahead of print 30 September 2019. DOI: 10.1177/1460458219874641.

19.

Fouad

Hassanein

Soliman

, et al. Analyzing patient health information based on iot sensor with ai for improving patient assistance in the future direction. Measurement 2020; 159: 107757.

20.

Mohan

Thirumalai

Srivastava

Effective heart disease prediction using hybrid machine learning techniques. IEEE Access 2019; 7: 81542–81554.

21.

Kumar

Vimala

Britto

KA.

A cognitive technology based healthcare monitoring system and medical data transmission. Measurement 2019; 146: 322–332.

22.

Mantzana

Themistocleous

Irani

, et al. Identifying healthcare actors involved in the adoption of information systems. Eur J Inform Syst 2007; 16(1): 91–102.

23.

Wesley

Schubel

Hsiao

, et al. A socio-technical systems approach to the use of health it for patient reported outcomes: patient and healthcare provider perspectives. J Biomed Inf X 2019; 4: 100048.

24.

Muzny

Henriksen

Giordanengo

, et al. Wearable sensors with possibilities for data exchange: analyzing status and needs of different actors in mobile health monitoring systems. Int J Med Inform 2020; 133: 104017.

25.

Kekade

Hseieh

Islam

, et al. The usefulness and actual use of wearable devices among the elderly population. Comput Methods Programs Biomed 2018; 153: 137–159.

26.

Talukder

Sorwar

Bao

, et al. Predicting antecedents of wearable healthcare technology acceptance by elderly: a combined sem-neural network approach. Technol Forecasting Social Change 2020; 150: 119793.

27.

Botrugno

Telemedicine in daily practice: addressing legal challenges while waiting for an eu regulatory framework. Health Policy Technol 2008; 7(2): 131–136.

28.

Baali

Djelouat

Amira

, et al. Empowering technology enabled care using IoT and smart devices: a review. IEEE Sens J 2018; 18(5): 1790–1809.

29.

Burns

Greene

McGrath

, et al. Shimmer?—a wireless sensor platform for noninvasive biomedical research. IEEE Sens J 2010; 10(9): 1527–1534.

30.

Ivković

Veljović

Ranđelović

, et al. Odroid-xu4 as a desktop pc and microcontroller development boards alternative. In: Proceedings of 6th International Conference (TIO), Faculty of Technical Sciences, Čačak, Serbia, 28−29th May 2016. University of Kragujevac, ČAČAK.

31.