HealthyBroker: A Trustworthy Blockchain-Based Multi-Cloud Broker for Patient-Centered eHealth Services

Abstract

Delivering electronic health care (eHealth) services across multi-cloud providers to implement patient-centric care demands a trustworthy brokering architecture. Specifically, such an architecture should aggregate relevant medical information to allow informed decision-making. It should also ensure that this information is complete and authentic and that no one has tampered with it. Brokers deployed in eHealth services may fall short of meeting such criteria due to two key behaviors. The first involves violating international health-data protection laws by allowing user anonymity and limiting user access rights. Second, brokers claiming to provide trustworthy transactions between interested parties usually rely on user feedback, an approach vulnerable to manipulation by malicious users. This paper addresses these data security and trust challenges by proposing HealthyBroker, a novel, trust-building brokering architecture for multiple cloud environments. This architecture is designed specifically for patient-centric cloud eHealth services. It enables care-team members to complete eHealth transactions securely and access relevant patient data on a “need-to-know” basis in compliance with data-protection laws. HealthyBroker also protects against potential malicious behavior by assessing the trust relationship and tracking it using a neutral, tamper-proof, distributed blockchain ledger. Trust is assessed based on two strategies. First, all transactions and user feedback are tracked and audited in a distributed ledger for transparency. Second, only feedback coming from trustworthy parties is taken into consideration. HealthyBroker was tested in a simulated eHealth multi-cloud environment. The test produced better results than a benchmark algorithm in terms of data accuracy, service time, and the reliability of feedback received as measured by three malicious behavior models (naïve, feedback isolated, and feedback collective). These results demonstrate that HealthyBroker can provide care teams with a trustworthy, transparent ecosystem that can facilitate information sharing and well-informed decisions for patient-centric care.

1. Introduction

Modern health care employs emerging technologies such as cloud computing and blockchains to improve patient safety, health outcomes, service efficiency, and delivery models. Such efforts are dedicated to ensuring continuity of care in all services, including diagnostic, primary, and emergency care. Electronic health care (eHealth) is a modern health care delivery model defined by WHO (World Health Organization) [1] as “the use of information and communication technologies (ICT) for health.” The model is deployed to help implement the holistic patient-centered care (also called “shared care”) that comprises the core of modern health care services [2,3]. Patient-centered care puts patients at the heart of health care services provided based on shared, informed decision-making [3]. Services may include diagnostic, primary, preventative, rehabilitative, emergency, long-term, hospital, palliative, and home care. Patient-centered care enables clinicians to work with care teams to best tailor the services needed for a patient’s anticipated integrated-care pathway. This care requires, however, relevant medical information and data to flow seamlessly among and across health care settings. One obstacle to this is that discrete legacy heterogeneous information systems are not designed to share information across hospitals [3].

Today, however, advances in cloud-computing capabilities have been widely incorporated in health care services to facilitate collaborative patient-centered care. According to [4], cloud-computing is a key solution for addressing eHealth interoperability problems due to its ability to increase information accessibility, availability, and reliability across organizations. Cloud computing also enables easy information sharing and collaboration among care teams from multiple service providers [4,5]. Although the benefits have motivated health care providers to use multi-cloud eHealth services to allow for informed decisions [4,5], this raises information security, privacy, and trust concerns [4,5] related to complying with health-data-protection regulations [3]. In this environment, delivering eHealth services across multiple cloud providers demands a reliable, trust-aware, cloud-based brokering architecture that complies with applicable data-protection laws and ensures that patient information is complete, authentic, and unsullied. Not having an architecture with this level of security can deprive health providers of consortium and, more importantly, create life-threatening situations for patients should treatment decisions be based on invalid information [1,3].

Cloud-based brokering systems, which manage and ensure the delivery of cloud services, empower users by enabling them to deploy virtual infrastructures across cloud systems through intermediation and aggregation capabilities. In addition, such systems allow users to negotiate resource allocation among multiple sites [6]. Accessing health care information is crucial and challenging. It requires integrating the information collected by various independent health-service providers in a large eHealth cloud. Such a cloud can facilitate the medical information exchange between care services at geographically distributed settings. It should achieve this at reasonable prices while maintaining a high quality of service to all end users. Unfortunately, integrating various health care cloud services can be complex and difficult to manage. One solution for this is using a multi-cloud broker that can fulfill information requests from end users without them having to interact directly with single cloud providers [7]. Multi-cloud brokers can also facilitate integration among several clouds, ensure cloud portability between different cloud vendors, improve continuity of services, and increase service level agreement (SLAs) by diversifying and leveraging multi-cloud providers.

The existing literature is limited in terms of discussing cloud brokering solutions that can enhance patient-centered eHealth services. Many of the cloud service-brokers [8,9,10] reported on were designed as general solutions for domain-neutral applications and thus do not suit modern health care scenarios. These brokering systems would violate international “need-to-know” [3] health-data-protection laws because they allow anonymous users to engage in random service and information exchanges. This puts patient information at great risk for improper disclosure [3,11]. It also does not allow care-team members to identify the information source or the treatment point associated with the information. In order for a care team to follow a patient’s care plan, they require access to information collected at each care point along the care pathway. In these instances, care-team members can be service providers at one treatment point and service consumers at another point. The brokering systems described here do not enable this role exchange.

Furthermore, while some researchers have proposed solutions to assess and manage service trustworthiness [6,12,13,14], their approach is vulnerable to users who lie when rating the quality of service (QoS) they received against the SLA. These users can work individually or collectively to harm specific users or an entire system. Therefore, brokering systems need an additional layer of transparency that promotes consensus among care teams and guarantees their mutual trust. This layer should track health care service transactions, monitor QoS, and audit user feedback for credibility. This approach will detect malicious user feedback and help decrease malicious attacks.

One technology that can help brokering systems achieve these goals is the blockchain technology used to build trust-worthy ecosystems for distributed environments [15]. More specifically, blockchain is “a peer-to-peer distributed ledger technology for a new generation of transactional applications that establishes transparency and trust” [16] in which the ledger contains the digitally tracked asset transactions of a group of networked peers [15]. Compared to other cryptography-based solutions, blockchain uniquely provides a transparent tamper-proof trail of time-stamped block sequences that are algorithmically self-policed to support secure, private, and indelible transactions. This technology can prevent malicious user feedback in health care services by tracking user credibility and sharing that information with all care-team members in the ecosystem. This would fill the security and transparency gap in traditional multi-brokering systems and meet the security requirements of modern eHealth services.

To summarize, modern eHealth collaborative environments require multi-cloud brokering architectures that can identify care-team members and allow them to act as providers and consumers as needed based on a patient’s treatment plan. eHealth brokering systems also need to establish trust and transparency among the care-team members by auditing service transactions and feedback. With that need in mind, this paper proposes HealthyBroker, a novel, trust-building multi-cloud broker specifically tailored to improve patient safety, health outcomes, service efficiency, and care delivery models. As designed, HealthyBroker provides care teams with an ecosystem that facilitates timely, transparent, and trustworthy sharing of critical medical information.

The remainder of this paper is organized as follows. Section 2 gives an overview of related work. Section 3 provides a general overview of the proposed model. The system architecture is outlined in Section 4. Section 5 describes the methodology used in the study. Experimental results are presented in Section 6 and, finally, conclusions are drawn in Section 7 along with suggestions for future work in this area.

2. Related Work

Considerable literature exists that investigates cloud brokering services and trust management in cloud environments. We summarize some relevant approaches here. For instance, the EigenTrust algorithm [12] uses individual user upload histories to generate a trust value for that user in peer-to-peer file-sharing networks. Following this approach, the system can identify malicious users and isolate them to minimize harm. In [17], a hardware security module is presented to prevent cloud administrators from tampering with the security of guest virtual machines. The private cloud monitoring system (PCMONS) [14] was developed as a modular monitoring system for private clouds. Basically, it gathers and prepares information relevant for data visualization and can be integrated with other cloud management toolkits such as Nagios [9]. The optimized infrastructure services (OPTIMIS) scheme, introduced in [8] for private clouds, allows interaction with a rich ecosystem of public clouds and many cloud providers. OPTIMIS can identify, capture, and codify a “picture” of an optimized cloud ecosystem driven by trust, risk, eco-efficiency, and cost. Its framework supports deployment and runtime decisions based on prior evaluation of providers. As another example, the architecture in [18] can build a cloud infrastructure from volunteer resources shared by their owners. On top of the infrastructure, an extra layer is added to provide QoS and SLA and eliminate unreliable, intermittent cloud providers. In [19], a reputation-based, trust-supporting framework is introduced. It includes a coherent, adaptive trust model for quantifying and comparing the trustworthiness of peers based on transactions from a feedback system. It introduces three trust parameters (user feedback, total transactions, and credibility of feedback sources), along with two adaptive factors (transaction context factor and community context factor). It combines these factors to compute a general trust metric. T-Broker [6] is a trust-aware service-brokering scheme proposed for multi-cloud environments. T-Broker implements a hybrid and adaptive trust model that calculates the overall degree of trust using the maximum deviation method to compute the direct trust (first-hand trust) of service resources. This can overcome some traditional trust model limitations in which the trusted attributes are judged subjectively. T-Broker uses the lightweight trust feedback algorithm [6] for trust computation. Lightweight collects locally generated user feedback and aggregates it to yield global evaluation scores for future transactions based on Equation (1):

$$Lightweight=\frac{P+1}{P+N+2}$$

(1)

where P is the number of positive ratings and N is the number of negative ratings. The lightweight trust algorithm [6] involves simple arithmetic operations and a counting operation. Therefore, it was used as a benchmark for our system.

The blockchain technology described earlier is gaining increasing attention as a way to track reputation in a distributed environment [20]. For example, it was used in [20] to build a reputation-aware solution that can track cache content in a vehicular environment. This solution uses blockchain to ensure reputation and enhance trust between provider and consumer (in this case, cache stores and consumer vehicles). However, it has not been applied to multi-cloud brokers or eHealth applications.

The authors in [21] introduced a deep-learning-based methodology for monitoring critical infrastructures using restricted boltzmann machine-based clustered intrusion detection system (RBC-IDS). The RBC-IDS technique classifies intruders from sensory data collected from wireless sensor networks (WSNs). However, the overhead computation cost is high.

An IoT-based health care monitoring system has been proposed in [22]. Its aim is to provide home-based health care monitoring. Based on the results, the system efficiently monitored patient symptoms remotely and in real time. However, the authors did not consider the security and trust issues regarding the exchanged patient data.

In [23], the authors introduced a framework that provides a secure cloud service for smart connected vehicles in a smart city. The authors proposed the use of a deep-belief network and decision tree for intrusion classification. The results showed the system’s accuracy to be 99.92%, which is very high.

The authors in [24] proposed using the clustered hierarchal hybrid-intrusion detection system (CHH-IDS) to ensure that WSNs used in smart grid applications operate in secure environments. The simulation was run on real datasets, and the accuracy improved when using random forest.

Although most of the above solutions are general and do not apply to health care, the authors in [25,26,27,28] propose solutions that are tailored specifically for modern health care services by managing resources or controlling access to shared data. In [25], the authors designed and deployed a sensor medium access control-based model to control access to epilepsy patients’ monitoring systems. Resources were managed in [26] by developing a smart health care framework, while authors in [28] built a smart health care reward model for resource allocation in a smart city. The authors in [27] helped with the early detection and prediction of cancer patients by designing a secure health care data-system architecture. However, although such solutions were tailored for health care services, some were limited to resources relevant to specific health services (like epilepsy care services for example). Moreover, they are vulnerable to malicious users as no mechanisms were deployed to achieve trustworthiness and transparency.

The main drawback of all the previously reviewed systems is that they do not check the credibility of incoming feedback to identify malicious users. In contrast, [13] introduces CloudArmor as a decentralized reputation-based trust management framework designed to deliver “trust as a service” (TaaS). This goal is achieved by spanning various distributed nodes so that users can provide their feedback or inquire about the trust results. CloudArmor measures the credibility of trust feedback to protect cloud services from malicious users.

Based on the above literature survey, it appears that existing brokering models for cloud computing have two main limitations. First, all except CloudArmor [13] rely on directly monitoring information or feedback from users without evaluating feedback credibility. Second, they fail to consider the particular needs of patient-centered care in modern eHealth services. Modern eHealth services require architectural models that can bridge this gap by offering a service broker for multi-cloud environments that can identify care-team members, grant them access to anticipated treatment points and patient data on a “need-to-know” basis, prevent malicious user behavior, and ensure the service’s trustworthiness.

3. System Overview

Sharing patient information is fundamental to successfully operating a health care system. The right information must be seamlessly accessible to the right care team member at the right time across discrete heterogeneous parties in various health care settings [29,30]. HealthyBroker achieves this by proposing a multi-cloud eHealth service broker architecture that allows care-team members to provide and consume cloud services on a “need-to-know” basis. Such services are related to the integrated care pathways in generic health care settings and include, among others, diagnostic, primary, preventative, rehabilitative, emergency, long-term, hospital, palliative, and home care. At the core of this system is a virtual cloud-based electronic patient record, as illustrated in Figure 1. The storing, accessing, and processing of these records should only be done by trustworthy care team members. For example, when a patient follows an anticipated care pathway that implements a treatment plan, a care team member collects information during a treatment point using HealthyBroker. To ensure care continuity, once the patient moves to the next treatment point, another care team member caring for this patient uses HealthyBroker to request access to relevant information previously recorded. Additionally, HealthyBroker maintains care provider’s ownership to information collected locally and even after sharing using blockchain technology. However, this information still needs to be shared among trusted care team members, and therefore, HealthyBroker ensures trust by assessing and tracking it using a neutral tamper-proof distributed blockchain ledger. Trust is assessed among team members based on two factors: meeting the QoS in the SLA, and the care team’s feedback on exchanged services. The service transactions and user feedback are tracked and audited in the immutable distributed ledger that provides a tamper-proof trail of block sequences across service providers and users. To accomplish this, HealthyBroker mandates that each user provide positive or negative feedback on his/her last service transaction based on the SLA. However, only feedback coming from trusted parties (with QoS matching SLA) is taken into consideration. The total of all trusted feedback values (positives and negatives) of a specific user is used to calculate the user’s reputation, as shown in Equation (2):

$$Rep\left(y\right)=\frac{{\sum }_{x=1}^{\left|Tf\right(y\left)\right|}Tf(x,y)}{\left|Tf\right(y\left)\right|}$$

(2)

where:

Figure 1. HealthyBroker environment.

• $\left|Tf\right(y\left)\right|$ number of trusted feedback received on provider y.
• $Tf(x,y)$ trusted feedback of user x on provider y.

Reputation of provider y ($Rep\left(y\right)$) is used by user x to calculate trust on provider y ($T_r(x,y)$) based on Equation (3):

$$T_r(x,y)=\left\{\begin{array}{cc}\mathrm{High}\mathrm{trust}\hfill & ifRep\left(y\right)\ge \rho \hfill \\ \mathrm{Medium}\mathrm{trust}\hfill & ifRep\left(y\right)\ge \mu \hfill \\ \mathrm{Low}\mathrm{trust}\hfill & ifRep\left(y\right)\ge \epsilon \hfill \\ \mathrm{New}\mathrm{provider}\hfill & ifRep\left(y\right)=\phi \hfill \end{array}\right.$$

(3)

where:

• $\rho$ denoted as threshold for high-trust providers.
• $\mu$ denoted as threshold value of medium-trust providers.
• $\epsilon$ denoted as threshold value of low-trust providers.
• $\phi$ defined a threshold value to represent new providers.

These values are experimental variables and can be tuned based on the trust level required by the system. In addition, in HealthyBroker we have imposed three levels of trustworthiness to allow users to choose different levels of trust that are inversely correlated with time consumed to calculate trust values. For instance, if the user wants only good providers he can choose a high trust level. However, this will result in long delays due to the time required for calculating such high trust values.

4. Layered Architecture

The HealthyBroker model collects user feedback and aggregates it to evaluate cloud service providers based on their reputations. Additionally, the system architecture is designed to evolve trustworthiness capabilities in brokering systems. Figure 2 illustrates the system architecture, which comprises the following three layers:

Figure 2. HealthyBroker architecture. Service level agreement (SLAs), quality of service (QoS).

• Health service layer: Care-team users request a service through this layer along with the SLA that meets their needs. Once they receive the service, they provide their feedback, which is checked by the system to ensure user credibility. A credible user will provide positive feedback for service that matches the SLA and negative feedback otherwise. On the other hand, a non-credible user will do the opposite.
• HealthyBroker layer: This layer tracks each provided service in a distributed ledger and the user’s credibility level for this service along with the provider’s trust level, and QoS. This layer includes three modules:
  • Monitoring manager: This module calculates the provider’s trust level by checking the QoS he/she provides against the SLA.
  • Feedback manager: This module calculates the user credibility level by comparing user feedback against the QoS provided. If they match, then the user is considered honest. This increases the credibility level. Otherwise, the level decreases.
  • Service transaction ledger: This module links the feedback and monitoring components by updating the service transaction ledger once a service is provided. The update includes the QoS provided, the user’s credibility level, and the provider’s trust level. This information is stored in a distributed immutable ledger that is shared among all care-team members.
• Infrastructure layer: In this layer, cloud service providers offer a virtual machine (VM) with different configurations of hardware, CPU, memory space, and hard-disk capacity. This layer manages all resources offered by service providers.

Figure 3, Figure 4 and Figure 5 show the main algorithm of HealthyBroker in pseudo code, flowchart, and interaction diagram representations. The system works as follows. Once a service request arrives from a user, the system calculates the credibility of each provider of this service and sends a list of these providers along with their reputation levels. The user selects a provider based on the level of trust desired. The system mandates that the user rate his last transaction by giving negative or positive feedback. Once the feedback is received, it is checked against the real-time monitored QoS provided to the user. If the feedback is correct, the user credibility level in increased by one and vice versa.

Figure 3. HealthyBroker flowchart.

Figure 4. HealthyBroker algorithm pseudo code.

Figure 5. Interactions between the users and HealthyBroker model.

5. Evaluation Methodology

To evaluate HealthyBroker, a multi-cloud model was built on NetBeans integrated development environment (IDE) 8 using the peer to peer (P2P) simulator in [31]. The experimental setting considered 50,000 transactions related to patient treatment, 25,000 medical files, 50 care-team members as users, and the following three types of malicious behaviors with different percentages of presence in the cloud environment (from 10% to 70%):

• Naïve malicious: This malicious model provides negative feedback to care-team members who sent them valid services. Additionally, they provide inauthentic files.
• Feedback malicious isolated: This malicious model provides positive feedback to an anonymous user from outside the patient-trusted care team who sent them an invalid file.
• Feedback malicious collectives: This malicious model represents sets of cooperative users who know one another. Each user from these sets gives all users in these sets high trust values and gives low trust values to all other users.

The threshold values used to compute the trust, defined in Equation (3), are experimental variables and can be tuned based on the level of trust. In this paper, we defined these values as follows:

• ρ denoted as threshold for high trust providers where the reputation $Rep\left(y\right)>0.8$.
• μ denoted as threshold value of medium trust providers where reputation $Rep\left(y\right)>0.4$.
• ε denoted as threshold value of low trust providers where reputation $Rep\left(y\right)>0.01$.
• φ defined a threshold value to represent new providers, the reputation $Rep\left(y\right)=zero$.

Furthermore, the lightweight trust algorithm [6] was used as a benchmark, and the following three performance indicators were considered:

• Accuracy: This measure checks whether the proposed brokering algorithm can accurately provide a trust measurement by calculating the mean absolute deviation (MAD) as follows:

  $$MAD=\frac{\sum Rep\left(y\right)-\overline{Rep\left(y\right)}}{n}$$

  (4)

  where $Rep\left(y\right)$ is the reputation of provider y (Equation (2)), $\overline{Rep\left(y\right)}$ is the mean of provider y’s reputations, and n is the number of feedback received on provider y.
• Service time: This measure specifies the time from when the system receives a user request to when the service is delivered.
• Feedback reliability: This measure represents the amount of user feedback received from non-malicious users.

6. Results and Discussion

To assess the HealthyBroker system, we compared it to a benchmark, the lightweight trust algorithm. Table 1, Table 2 and Table 3 and Figure 6, Figure 7 and Figure 8 present the results obtained from the MAD measure considering the naïve, isolated, and collective malicious user models, respectively. From the tables, it is clear that decreasing the percentage of malicious user models leads to the MAD increasing. Also, the accuracy increases in HealthyBroker in contrast to lightweight trust. The figures illustrate the differences between the HealthyBroker and lightweight trust algorithms more clearly in the instances when malicious collective, isolated, and naïve users are introduced to the system, respectively. A small percentage of malicious users (10%) was used initially, and this percentage was increased gradually to 70%. The results across all figures clearly show that HealthyBroker performs considerably better than the benchmark. This occurs because HealthyBroker considers direct and indirect trust parameters, while the lightweight trust algorithm considers only the indirect parameters.

Table 1. Mean absolute deviation (MAD) results with naïve malicious.

	Percentage of Malicious
	10%	30%	50%	70%
HealthyBroker	0.199827	0.091433	0.061557	0.05144
Lightweight trust	0.468135	0.417374	0.398155	0.317507

Table 2. MAD results with feedback malicious isolated.

	Percentage of Malicious
	10%	30%	50%	70%
HealthyBroker	0.079445	0.053207	0.043396	0.040154
Lightweight trust	0.816009	0.802237	0.707643	0.606073

Table 3. MAD results with feedback malicious collective.

	Percentage of Malicious
	10%	30%	50%	70%
HealthyBroker	0.099427	0.073312	0.053462	0.043296
Lightweight trust	0.820141	0.742743	0.637262	0.600131

Figure 6. Mean absolute deviation (MAD) result with naïve malicious.

Figure 7. MAD result with feedback malicious isolated.

Figure 8. MAD result with feedback malicious collectives.

In addition, the service time was measured with the different provider reputation levels. Table 4, Table 5, Table 6 and Table 7 and Figure 9, Figure 10, Figure 11 and Figure 12 list the findings. However, we note that high-trust providers consumed more service time than low and medium-trust providers. Moreover, the feedback malicious collective consumed more time than isolated and naïve because of its cooperative strategies. From the figures, the observed correlation between the service time and level of trust is explained with different percentages of malicious users. Nevertheless, in some cases, the difference was not significant when decreasing the number of malicious users.

Table 4. Service time with 70% malicious.

	Naïve	Isolated	Collective
High	3.064	3.696	9.817
Medium	2.98	3.329	9.786
Low	2.243	2.441	6.837
No trust	3.85	3.098	7.229

Table 5. Service time with 50% malicious.

	Naïve	Isolated	Collective
High	5.512	7.732	5.614
Medium	4.504	6.682	5.113
Low	2.804	6.529	65.192
No trust	3.477	3.117	5.499

Table 6. Service time with 30% malicious.

	Naïve	Isolated	Collective
High	5.163	5.847	6.213
Medium	4.454	4.326	4.821
Low	4.026	4.028	4.511
No trust	4.924	6.863	5.514

Table 7. Service time with 10% malicious.

	Naïve	Isolated	Collective
High	3.211	4.138	5.375
Medium	2.939	4.004	4.91
Low	2.099	4.017	1.266
No trust	3.734	3.334	6.819

Figure 9. Service time with 70% of malicious.

Figure 10. Service time with 50% of malicious.

Figure 11. Service time with 30% of malicious.

Figure 12. Service time with 10% of malicious.

Therefore, we measured the feedback reliability when naïve, isolated, and collective malicious users are introduced. As shown in Table 8, Table 9 and Table 10, when the level of trust increases, the percentage of malicious decreases and vice versa. In addition, we can see that "No Trust" in feedback reliability is the same in all cases. This is because “No Trust” denotes a new provider in HealthyBroker. Thus, there is no feedback reported for this new provider.

Table 8. Feedback reliability result with naïve malicious.

	Percentage of Malicious (Naïve)
	10%	30%	50%	70%
High	81	68	41	20
Medium	97	80	55	35
Low	49,720	49,751	49,762	49,781
No trust	102	101	102	102

Table 9. Feedback reliability result with feedback malicious isolated.

	Percentage of Malicious (Isolated)
	10%	30%	50%	70%
High	49	47	25	10
Medium	63	40	24	12
Low	49,786	49,786	49,786	49,786
No trust	102	101	102	102

Table 10. Feedback reliability result with feedback malicious collective.

	Percentage of Malicious (Collective)
	10%	30%	50%	70%
High	53	47	23	12
Medium	76	48	25	16
Low	49,769	49,804	49,850	49,870
No trust	102	101	102	102

7. Conclusions

Cloud-brokering systems have emerged to improve cloud-computing services, especially in multi-cloud environments for collaborative environments. Delivering electronic health care (eHealth) services across multi-cloud providers to implement patient-centric care demands a trustworthy brokering architecture that can ensure that shared patient information among multi-care providers is complete and authentic and that no one has tampered with it. However, existing brokering models fall short in addressing these special requirements of patient-centered eHealth services holistically. In this work, we introduced HealthyBroker, a multi-cloud blockchain-based eHealth service model that meets such needs. Following an anticipated treatment pathway for a planned treatment, the care team member uses HealthyBroker at a treatment point to access relevant patient information needed for informed-decision making. HealthyBroker also ensures service trustworthiness against malicious behavior by managing trust among care teams. It uses blockchain technology to track each service, the user’s credibility, and providers trust in a neutral ledger creating a tamper-proof trail of block sequences distributed among service providers and users for transparently.

The service time, accuracy, and reliability of received user feedback were measured to test HealthyBroker’s performance in a simulated multi-cloud environment using three malicious behavior models: Naïve, feedback isolated, and feedback collective. The experimental results show that HealthyBroker outperformed the benchmark algorithm, lightweight trust, in all scenarios. The differences between the HealthyBroker and lightweight trust algorithms are most clear in the instances when malicious collective, isolated, and naïve users are introduced to the system, respectively. Furthermore, results show that HealthyBroker performs considerably better than the compared benchmark because HealthyBroker considers direct and indirect trust parameters, while the lightweight trust algorithm considers only the indirect parameters. However, high-trust providers consumed more service time than low and medium-trust providers, while the feedback malicious collective consumed more time than isolated and naïve because of its cooperative strategies. In terms of future research, it would be valuable to explore other types of malicious behaviors such as Sybil attacks and malicious spies. Ultimately, it is hoped that this solution will lay a sound foundation for future trust management solutions that tackle loss of trust and the adoption of blockchain technology in multi-cloud environments.