HealthBlock: A Framework for a Collaborative Sharing of Electronic Health Records Based on Blockchain

Abstract

Electronic health records (EHRs) play an important role in our life. However, most of the time, they are scattered and saved on different databases belonging to distinct institutions (hospitals, laboratories, clinics, etc.) geographically distributed across one or many countries. Due to this decentralization and the heterogeneity of the different involved systems, medical staff are facing difficulties in correctly collaborating by sharing, protecting, and tracking their patient’s electronic health-record history to provide them with the best care. Additionally, patients have no control over their private EHRs. Blockchain has many promising future uses for the healthcare domain because it provides a better solution for sharing data while preserving the integrity, the interoperability, the availability of the classical client–server architectures used to manage EHRS. This paper proposes a framework called HealthBlock for collaboratively sharing EHRs and their privacy preservation. Different technologies have been combined to achieve this goal. The InterPlanetary File System (IPFS) technology stores and shares patients’ EHRs in distributed off-chain storage and ensures the record’s immutability; Hyperledger Indy gives patients full control over their EHRs, and Hyperledger Fabric stores the patient-access control policy and delegations.

1. Introduction

Most existing healthcare organizations use local databases to hold the EHRs of their patients. However, even if they do their best to protect their clients’ private information, this solution suffers many drawbacks. In fact, during their lifetime, patients usually request different healthcare-service providers, and their EHRs will be scattered, and critical information might not be available anywhere at vital moments. This scenario is frequent, even if the patients’ healthcare providers are in the same city. The situation will be the worst for people that visit healthcare providers in different countries.

The patients themselves do not always have access to all their records, and they have no control over who can access what. As a result, sensitive information is sometimes leaked, causing damage to their owners: losing a job, increased insurance fees, etc.

Several new building blocks (blockchain, Hyperledger, IPFS, etc.) are now available to develop secure architectures for different applications more easily and even with new highly requested features. Classical cryptographic systems (encryption, signature, hash, etc.) provide basic blocks to easily achieve certain security properties, such as confidentiality, integrity and authentication. However, other objectives (availability, transparency, immutability, automation, etc.) require, in addition to the combination of several classic cryptographic systems, the integration of other concepts (peer-to-peer networks, consensus algorithms, smart contracts, etc.). IPFS [1], for example, uses the Bitswap peer-to-peer network (a generalization of the BitTorrent protocol) [2], the GIT version management system [3], a self-certifying file system (SFS) [4] and the hash tree (Merkle tree) to distribute files across multiple nodes to avoid a single point of failure or the need of trusted nodes. Hyperledger and blockchain use peer-to-peer networks, consensus algorithms, smart contracts, signature, hash functions, ZKP protocols, etc., to achieve interesting properties, such as availability, integrity, transparency, traceability and automation. Using smart contracts for instance, we can automatically trigger, under certain conditions, some processing without the intervention of any trusted authority. The contract is executed, even if the expected results are against the will of the stakeholders.

These new emerging technologies, including blockchain, provide a better solution for patients’ record protection, accessibility, delegation, anonymity and other useful features.

The main goal of this paper is to address the problems of the existing EHR management systems by providing a solution with interesting features, such as the following:

• The EHRs are appropriately protected (Integrity + Confidentiality) and available anytime from any country.
• The patients have full control of their EHRs, and they can temporarily delegate access to any person or organization at any time.
• The patients can obtain anonymous healthcare services, when needed, to better protect their privacy.
• The patients’ attributes can be proved remotely, making telemedicine more efficient.
• The solution takes into consideration that in an emergency, the patients may not have their full capacity to grant access to their EHRs.

Different technology, including Hyperledger Fabric, Hyperledger Indy, and the IPFS database, are combined to access these goals.

The remaining part of this paper is organized as follows. Section 2 presents the related work. Section 3 recalls some preliminary notions useful to understand the proposed architecture. Section 4 gives the proposed framework architecture for sharing EHRs. Section 5 provides a prototype as a proof of concept. Section 6 discusses the proposed approach, and Section 7 provides some concluding remarks.

2. Related Work

We have studied many research papers related to EHR management systems during the last few years. We can evaluate them according to some useful criteria, including the following:

• Patients have full control over their EHRs: Patients keep their EHRs in their wallets or saved in some store in an encrypted form, and they control who can access which selected attributes and when.
• Anonymous Healthcare Service: It will be nice if the solution gives patients the possibility to obtain an anonymous service when they want. Patients hold a set of attributes related to their identity, including EHRs, and show only what it is required. For instance, to obtain a COVID-19 vaccine, patients may need only to show that they are older than a certain age; they are citizens of the city where they ask for the vaccine and have not received the vaccine yet.
• Availability: It is very important that the EHRs are available anytime from any location, even if some equipment is down or attacked.
• Integrity: We should ensure that EHRs have not been accidentally or maliciously changed. Without integrity, EHRs are useless.
• Confidentiality: EHRs contain very sensitive information, and if disclosed, some serious damages can take place for their owners, including loss of jobs and increasing insurance fees.
• Access Control Delegation: Any solution that aims to manage EHRs should give the patient an easy way to delegate some access to any attributes related to their EHRs.
• Zero-Knowledge Proof (ZKP): It could be useful for patients to prove some properties related to their attributes without revealing their values. For example, they can prove that they are more than 18 years old without revealing their exact age. Commonly, some blockchain used ZKP protocols to provide this kind of property.
• Emergency Access to EHRs: In the case of an emergency when the patient is not in his full capacity to provide, by himself, his EHRs, a secure alternative solution should be provided.
• Scalability: When blockchain is used, we should carefully evaluate the volume of data added every day and be sure that the solution stays scalable, even when billions of clients are involved.
• Interoperability: To maximize its interoperability, any solution should use standards and, when needed, blockchain should be public and available worldwide.
• Remote Health Service: EHRs management solutions should provide the possibility of remote consultations, a growing need, particularly in the COVID-19 context. This could be possible, particularly when patients can remotely prove their attributes.

Hereafter, we shortly describe the main interesting EHRs management solutions that we included in our comparative studies.

Sun et al. proposed in [5] a scheme to efficiently and securely store electronic medical data. They used attribute-based encryption techniques combined with blockchain technology to control electronic medical data access. The EHRs are encrypted and stored in the decentralized InterPlanetary File System (IPFS) storage, providing scalability, privacy and preventing a single point of failure.

Kumar et al. proposed in [6] distributed off-chain storage to manage patients’ medical data. They stored the medical records in the IPFS and their indexes in the blockchain. The approach aims to provide consistency, integrity, and availability for medical data.

In [7], Khatoo proposed an Ethereum-based solution to manage healthcare records, where the social security number is used to map the users’ Ethereum address. The author uses smart contracts to provide the flexibility, interoperability, and accessibility of patients’ medical data.

Nguyen et al. proposed in [8] an EHR sharing framework on a mobile-cloud platform. They used Ethereum blockchain technology hosted on Amazon Cloud to implement a health data sharing framework on mobile clouds and protect patients’ sensitive information from malicious attacks. Additionally, they profited from the smart contracts on Ethereum to manage access control on these EHRs.

In [9], Shen et al. provided a blockchain-based solution called MedChain to share medical data efficiently. MedChain combines blockchain technology, digest chains, and structured peer-to-peer network techniques to overcome the efficiency issues in the existing solutions for sharing healthcare data. $MedChain$ consists of two different peer nodes, namely super peers (such as national hospitals having servers with high computing and storage capacities) and edge peers (such as community clinics that store local patients’ data).

In [10], Niu et al. suggested a secure EHRs sharing schema based on permissioned blockchain. The approach supports multiuser search and uses the ciphertext-based attribute encryption mechanism to achieve data confidentiality, provides a fine-grained access control, and prevents malicious doctors from uploading false information through an authenticated access.

Shahnaz et al. proposed in [11] an Ethereum-based blockchain architecture to handle EMRs. They used Solidity to write smart contracts that control access to healthcare records.

Kim et al. suggested in [12] a data-sharing medical questionnaire management system based on blockchain technology. They leveraged blockchain characteristics to guarantee the integrity of data. They also addressed the scenario when a third party requests some EHRs attributes requiring the patient’s permission.

In [13], Dagher et al. leveraged Ethereum blockchain technology features and proposed a framework called $Ancile$ to secure and appropriately control access to EHRs that should be made available to various users (patients, providers, and third party) under different conditions.

Fan et al. suggested in [14] a framework called $MedBlock$ based on blockchain technology to manage access control on EHRs. Using $MedBlock$, the patients can easily share and access their EHRs with the minimum energy consumption.

In [15], Liu et al. proposed a scheme for electronic medical records (EMRs) sharing and privacy-preservation based on blockchain technology called BPDS. In BPDS, the original EMRs are stored securely in a cloud storage under the management of smart contracts, and their indexes are stored in a consortium blockchain to ensure that EMRs cannot be falsified.

In [16], Al Omar et al. provided a privacy-preserving medical data platform based on a blockchain where medical data are encrypted and stored.

In [17], Dubovitskaya et al. proposed a blockchain-based framework for sharing EHRs for cancer patients. They leveraged permissioned blockchain features to achieve immutable, accountable, and fine-grained EHR access control. In this framework, the EHRs are encrypted using the patients’ public keys and stored in a cloud server. When the data are needed, it is necessary to obtain the data owner’s decryption key.

Liang et al. suggested in [18] a model for user-centric sharing data in eHealth systems. They leveraged a permissioned blockchain to protect the healthcare data privacy and enhance the decentralized identity management using membership services supported by blockchain. In this framework, the healthcare data are collected from different sources, including wearable devices, and stored in the cloud for sharing purposes between different providers and insurance companies.

Xia et al. [19] proposed $MeDShare$, an electronic medical records (EMRs) manager based on blockchain that provides access control for medical data in a trustless environment. EHRs are stored in the cloud, and access control is achieved through smart contracts.

In [20], Azaria et al. proposed MedRec medical data access and permission management system based on a permissionless blockchain technology. Additionally, this framework provides health data sharing between healthcare systems. The use of the blockchain technology provides accountability, confidentiality, traceability, and the sharing of EMRs. They designed three Ethereum smart contracts to achieve fine-grained access control for patients’ medical records. The blockchain does not store actual medical data; they remain in the healthcare system’s database.

Yue et al. [21] proposed a blockchain-based storage platform called Health Data Gateway (HDG) that allows patients to control and share their medical data without violating their privacy. The patient’s medical data are encrypted by the providers and stored in a private blockchain. When needed, the patient downloads his encrypted medical data, decrypts them using his private key, and decides whether to share them or not.

Many other eHealth solutions, such as [22,23], were proposed even before the appearance of the blockchain. They are often based on cryptographic primitives and crytoprotocols to ensure many security properties, such as the confidentiality and the integrity of EHRs.

Table 1. Commonalities of related work.

Blockchain Type	Blockchain Name	Smart Contract	Blockchain Role	EHRs Access Control	EHRs Privacy	EHRs Storage	Authors
Public	Ethereum	Yes	Save Address of EHRs	Attribute Based Encryption (ABE)	ABE	IPFS	Sun et al. [5]
			Save Addresses of Patients	Cloud EHR Manager	EHR Manager’s Public Key		Nguyenet al. [8]
						Off-chain Storage	Shahnaz et al. [11]
							Dagher et al. [13]
						Provider Local Database + Patient Database	Azaria et al. [20]
	Not fixed	No	Save hash value of EHRs	bread crumbs	Encryption technology	Local Database or Cloud	Fan et al. [14]
			Store data digest in Blockchain			Database	Shen et al. [9]
Consortium			Save keywords of EHRs	Attribute-Based Encryption		Cloud Storage	Niu et al. [10]
			Save hash of medical data	membership service component			Liang et al. [18]
			Save medical data	Not specified		Blockchain	Al Omar et al. [16]
			metadata + access control policy	Role-based		Local Database + Cloud	Dubovitskaya et al. [17]
			Stored hash of medical records	Not specified	Hash based data storage	IPFS	Kumar et al. [6]
		Yes	Reserve indexes of EMRs	Content extraction signature	Encryption technology	Cloud	Liu et al. [15]
			Questionnaire result data	According to medical policy		Blockchain	Kim et al. [12]
			save immutable database	Not specified		Database	Xia et al. [19]
Private		No	data stored in private blockchain	Access control model		Blockchain + Cloud	Yue et al. [21]
No Blockchain	No Blockchain		No Blockchain		Encryption technology + Cryptographic Protocols	Database	Sandıkkaya et al. [22]

resumes the different connection between the presented related work according to the used technologies. The evaluation of the related work according to the most required features of an EHR management system is given in Section 6.

3. Preliminaries

We start by briefly introducing the principal technologies involved in our architecture.

3.1. Blockchain Technology

A blockchain is a shared, immutable, distributed ledger of cryptographically signed transactions grouped into blocks. Each block is linked to the previous one by including its hash. Many nodes have the exact copy of the blocks and collaborate according to a consensus algorithm to add new transactions that respect predefined criteria.

3.1.1. Key Characteristics of Blockchain

• Ledger: Unlike traditional databases, transactions in a blockchain could not be modified or deleted.
• Secure: Blockchain intrinsically provides integrity, traceability, and availability.
• Absence of trust: A blockchain can fulfill its security properties, even if its nodes are operated by players that do not trust each other and have antagonist goals.

3.1.2. Blockchain Types

There are different types of blockchains and Hyperledgers. They could be public or private and with or without permission. For instance, Hyperledger can be accessible to everyone (public) but with different permission (some users can read, others can read and write). Another could limit the access to a reduced group (private), where each group member can have different permission (private, with permission). Different examples of public and private blockchain/Hyperledgers, with and without permission, are given in

Table 2. Blockchain Types.

	Without Permission	With Permission
	read and write	limited read or write
Public (access to everyone)	Bitcoin, Ethereum, IOATA, etc.	Hyperledger Indy (sovereign), IODB, etc.
Private (access to a limited group)	Hyperledger Sawtooth (permissionless mode)	Hyperledger Fabric, Iroha, Sawtooth, etc.

.

3.2. Smart Contracts

Smart contracts are self-executing computer programs deployed on the blockchain to generate new facts added to the ledger. They are utilized in different fields, such as healthcare, financial services, and government. They are also called $Chaincode$ in Hyperledger Fabric and written using different programming languages, such as Solidity, JavaScript, Go, Java and Rholang. Once it is deployed in the blockchain, a smart contract cannot be changed or removed. Usually, it simply waits for external events to execute some specific task and update the system’s state.

3.3. Hyperledger Indy

Indy [24] is a public permissioned Hyperledger specifically designed for digital identities, and it provides the reusable tools, libraries and components needed to implement them. The created digital identities are rooted in the Hyperledger, which is interoperable with other blockchains. More details about Indy are given in Section 4.1.3.

3.4. Hyperledger Fabric

The Linux Foundation created Hyperledger Fabric [25] in 2015. It aims to be a general-purpose Hyperledger that satisfies a broad range of applications. It is an open-source, modular, and permissioned Hyperledger that offers a granular access control.

3.5. InterPlanetary File System (IPFS)

The InterPlanetary File System (IPFS) [1] is an immutable and distributed file system for storing and sharing data. It works using a peer-to-peer (P2P) network. Files are stored in IPFS objects, and each object can contain up to 256 Kb of data as well as links to other objects. Big files are split into multiple objects, and a new object with an empty data containing the links to all slices is also created. IPFS provides a content-addressing technique to uniquely identify a file: the address of any file is simply its hash value. As in a blockchain, nodes do not need to trust each other, and the files remain available, even if many nodes are disconnected. Files inserted in IPFS cannot be changed anymore, ensuring immutability, but it supports versioning. For every version of a file, a commit object is created and linked to each other to easily access to the history of each file.

4. Proposed Framework

The proposed framework is presented incrementally. We first present a core solution based on Hyperledger Indy, discussing its features. After that, we propose different extensions based on other exciting technologies such as Hyperledger Fabric [25], the IPFS [1], and Fido U2F [26].

4.1. Preliminaries

4.1.1. Roles

Three prominent roles are involved in this framework of collaborative sharing of ehrs framework based on blockchain technology:

• Patients: Patients play a crucial role, and the whole system aims to appropriately protect their EHRs and make them available to authorized participants when needed. Each document (a part of an EHRs, insurance, identity, etc.) contains a set of attributes (name, address, blood type, etc.) and a unique DID (decentralized identifier). Each DID is also associated with a public key and stored in the Hyperledger Indy. A patient proves that he is the owner of a document by showing he is the owner of the private key associated with the public correlated to the document referred by DID. The patients have full control of their EHRs. The system allows them to create and modify the access control policies related to their EHRs. This policy could be stored in Hyperledger Fabric or Ethereum. EHRs are varied and produced by different health service providers. To simplify the presentation, we assume that Bob is our patient.
• Healthcare providers: They are the producers and the consumers of healthcare attributes related to patients. They include individuals (doctors, nurses, etc.) and institutions (hospitals, labs, research centers, etc.). Once a healthcare attribute is produced or updated, any future access, inside or outside the same institution, should be consistent with the patient access control policy. To simplify the framework’s presentation, we assume that the provider is a laboratory L and the doctor Alice is the consumer.
• Healthcare card provider or insurance issuers: Using their healthcare cards or insurance, patients can receive services from different healthcare providers without directly paying them when they are appropriately covered.

4.1.2. Notations

In the remaining part of this paper, we adopt the following notation related to the cryptographic operations.

• $H\left(m\right)$ (Hashed message): A message m hashed by a hash function H, such as SHA-256, SHA3, RIPMD, Merkle-tree, etc.
• ${\left\{m\right\}}_k$ (Symmetric-key encryption): A message m encrypted by the key k using a symmetric cryptographic system, such as AES, 3-DES, etc.
• ${\left\{m\right\}}_{k_a}$ (Message encrypted with a public key): A message m encrypted with the public key $k_a$ using an asymmetric cryptographic system, such as RSA, El-Gamal, etc.
• ${\left\{m\right\}}_{k_a^{-1}}$ (A signed message): A message m signed with the private key $k_a^{-1}$ using an asymmetric cryptographic system, such as RSA, DSA, El-Gamal, etc.

4.1.3. Hyperledger Indy

It is a permissioned public Hyperledger where anyone can read from the ledger, but only authorized principals can write on it. It is based on Sovrin [27] and aims to offer a self-sovereign identity based on a blockchain. For example, the government of British Columbia uses it in Canada to implement its eID solution [28].

It could be seen as a ledger that contains certificates linking DIDs to public keys and signed by a Trust Anchor $\mathtt{TA}$. A $\mathtt{TA}$ is an individual or an organization (government, insurance, hospital, clinic, etc.) that is already known and trusted by Hyperledger Indy. They act as certification authorities, adding a new Trust Anchor to the ledger. They have the right to write in the ledger. Whenever a $\mathtt{TA}$ delivers a document (an Identity) containing fresh DID, they add a link (certificate) between the DID and its public key to Indy, as shown in

Table 3. Links between DIDs and public keys in Hyperledger Indy.

DID	PUBLIC-KEY	DID-$\mathtt{TA}$	{Hash(DID, PUBLIC-KEY, DID-$\mathtt{TA}$)}${}_{{\mathit{K}}_{\mathit{TA}}^{-1}}$
$D_a^0$	$K_a^0$	$D_{{\mathtt{TA}}_1}$	${\left\{H(D_a^0,K_a^0,D_{{\mathtt{TA}}_1})\right\}}_{K_{{\mathtt{TA}}_1}^{-1}}$
$D_a^1$	$K_a^1$	$D_{{\mathtt{TA}}_1}$	${\left\{H(D_a^1,K_a^1,D_{{\mathtt{TA}}_1})\right\}}_{K_{{\mathtt{TA}}_1}^{-1}}$
$D_b$	$K_b$	$D_{{\mathtt{TA}}_2}$	${\left\{H(D_b,K_b,D_{{\mathtt{TA}}_2})\right\}}_{K_{{\mathtt{TA}}_2}^{-1}}$
$D_c$	$K_c$	$D_{{\mathtt{TA}}_3}$	${\left\{H(D_c,K_c,D_{{\mathtt{TA}}_2})\right\}}_{K_{{\mathtt{TA}}_3}^{-1}}$
⋮	⋮	⋮	⋮

. This entry is added to the ledger to attest that the owner of the identity containing the DID $D_a$ is the one who knows the private key associated with $K_a$. The main information of this entry are “$D_a,K_a^0,\mathrm{DID}-\mathtt{TA},{\left\{H(D_a,K_a,\mathrm{DID}-\mathtt{TA})\right\}}_{K_{\mathtt{TA}}^{-1}}$”, where DID-$\mathtt{TA}$ is the DID of the Trust Anchor that has signed this record. Indy contains many transactions that have this kind of record. The same $\mathtt{TA}$ could sign many associations between DIDs and public keys, as shown in Table 3.

Hyperledger Indy also contains information related to $\mathtt{TAs}$. We find a certificate for each trusted authority containing its DID, its service endpoint (URI or IP address, transport protocol, and port), public key, the schema of its delivered documents (the list of attributes that could be found in the credential), etc. Therefore, having the DID of a document, we can easily obtain the producer’s public key and join him through its service endpoint.

Any part of an EHRs could be considered a credential containing a claims list of pairs(attribute, value). The credential also contains the proof of claims involving the issuer’s signature, as shown in Figure 1.

Assume that an agent B wants to prove to A that he has an attribute included in a credential containing the DID $D_b$; then, they need to proceed as follows:

• The agent B sends the credential containing the DID $D_b$ to A.
• A reads from Hyperledger Indy, the public key $k_b$ associated with the DID $D_b$.
• A asks B to prove that he owns the private key associated with $k_b$ using a challenge–response protocol such as the example of

  Table 4. Challenge–response protocol.

  1.	A	→	B	:	$\mathit{A},\mathit{B},{\mathit{N}}_{\mathit{a}}$
  2.	B	→	A	:	${\left\{H(A,B,N_a)\right\}}_{k_b^{-1}}$

  .
  At the first step, A sends to B a fresh random number $N_a$ (called a nonce and used as a challenge). At the second step, B returns the nonce signed using the appropriate private key $k_b^{-1}$.To verify if the challenge was answered correctly, A checks if the message was signed using the private key associated with $k_b$.

DIDs and public keys are randomly generated by the document’s owner in which the DID appears. DIDs and public keys are not necessarily correlated to the name of their owners, allowing them to receive anonymous services.

4.2. Ehrs Management Based on Indy

Indy can provide interesting EHRs management, where the patients hold wallets containing their attributes.

Assume that a patient, Bob, visited a laboratory L, and later he wants to give the doctor Alice access to some of his attributes produced by L. The main steps of the interaction between Bob, L, and Alice are shown in Figure 2.

• After visiting any EHRs attribute provider, such as a laboratory, the patient can ask any time, even remotely, for his attributes. He sends a request containing a DID and a public key kb. The laboratory verifies the identity of the patient and asks him to prove that he is the owner of the public key Kb using the challenge–response protocol shown in Table 4.
• Once the patient’s identity and ownership of the public key Kb have been proven, the laboratory creates a certificate attesting that DID belongs to the owner of Kb and saves it in Hyperledger Indy as shown in

  Table 5. Data Location.

  Data Location	Patient Wallet	Indy	IPFS
  EHRs	✓		✓
  DID-Key certification		✓

  ✓ means that the data given in line are saved in the location given in the column. An empty case means that the data given in line is not in the location given in the column.

  .
• The laboratory creates a signed document containing the DID, the requested attributes, their values and sends it to the patient.
• The patient saves these attributes in his wallet as shown in Table 5 and can provide them for any future need. For example, suppose that a doctor requests these attributes, then the patient uses his wallet and provides them.
• The doctor Alice gets the public key Kb associated with DID from Indy.
• Alice asks the patient Bob to prove that he is the owner of the Kb by using a challenge–response protocol shown in Table 4.

This simple architecture provides numerous advantages, as shown in

Table 6. Features of the solution based on Indy.

	Features	Patient Controls Access to his EHRs	Anonymous Healthcare Service	EHR-Availability	EHR-Confidentiality	EHR-Integrity	EHR-Access Control Delegation	EHR-Zero-Knowledge Proof	EHR-Emergency Access	Scalability	Interoperability	Remote Health Service
Approach
Indy EHRs		✓	✓	+-	+-	+-		✓	✓	✓	✓	✓

✓ means that the proposed approach has the corresponding feature. An empty case means that the proposed approach does not have the corresponding feature. +- means that this feature is not always present, it depends on the provider-side security level. ✓: The red color for the check mark indicates that this feature is provided by this approach, but it is not the case for those presented in state of the art (see Section 6 ).

.

Finally, it is worth mentioning that Indy also handles the revocation of DIDs in case a wallet is lost or hacked.

4.3. Module I: Access Control Delegation

We want to improve the previous version of EHRs access control management as follows:

• The patient does not necessarily need to carry his attributes in a wallet. He can obtain them any time by contacting their providers.
• The patient can delegate his access control rights to any trusted third party as shown in

  Table 7. Roles and actions.

  	Roles	Patient	EHR Provider	EHR Consumer
  Action on EHRs
  Creation			✓
  Encryption			✓
  Upload			✓
  Access		✓	✓	after patient’s permission
  Delegate permission		✓
  Modify			✓

  ✓ means that the role indicated in the column is authorized to perform the action shown in the row. An empty box means that the action is not allowed for the corresponding role.

  . A delegation is a kind of certificate that associates a DID with a set of attributes and a set of public keys. More precisely, a delegation has the form shown by Equation (1) and states that the attributes $a{t}_1,\dots ,a{t}_n$ of the patient known by $DID$ can be accessed by anyone having a key in $p{k}_1,\dots ,p{k}_m$ until a deadline $Time$:

  $$\underset{D}{\underbrace{DID,a{t}_1,\dots ,a{t}_n,p{k}_1,\dots ,p{k}_m,Time}},{\left\{H\left(D\right)\right\}}_{k_b^{-1}}$$

  (1)
  The hole delegation policy is specified by a list of rules given in the format of Equation (1) which corresponds to the ABAC model [29]. In fact, each rule specifies the subjects by their public keys ($p{k}_1,\dots ,p{k}_m$), the objects by their names ($a{t}_1,\dots ,a{t}_n$), the action (read) is implicit, and the context by ($Time$). Of course, we can enrich the rule to take into account other contexts attributes (location, etc.). Additionally, instead of fixing the public keys of the subjects, we can fix some of their attributes (role, department, and hospital). In this case, the subjects need to prove their attributes before getting access to the specified objects. The subject attributes and the proof of their ownership could be handled using Indy in the same manner as proving the ownership of other medical attributes.

The architecture of the updated solution is as shown in Figure 3, and it is used as follows:

• The patient asks the laboratory to attest that he is the owner of the pair ($DID$, $kb$). Additionally, he provides the identity that allows the laboratory to identify him; this could be another DID.
• The laboratory asks the patient to prove that he is B and he is the owner of $Kb$. B can use any DID related to his public key, by which the laboratory can know him.
• The laboratory certifies the link between $DID$ and $Kb$ and saves it in Indy as shown in Table 5. At the same time, it certifies and keeps secret the link between $DID$ and B (i.e., ${\{B,DID\}}_{k_l}$). This link can be saved locally by the laboratory or encrypted using its public key and returned to the patient. Later, when the doctor asks for attributes related to $DID$, the link between $DID$ and B (i.e., ${\{B,DID\}}_{k_l}$) should be provided or recovered.
• The patient can add the delegation related to any subset of his attributes using Hyperledger Fabric.
• The patient visits the doctor and provides him with the $DID$ and the list of attributes $a{t}_1,\dots ,a{t}_n$ that he can obtain from the laboratory.
• The doctor obtains the public key $kb$ associated with $DID$ from Indy as well as the service endpoint of the trusted provider that certifies this link.
• Using the public key $kb$, the doctor asks the patient to prove that he is its owner using the challenge–response protocol given by Table 4.
• Using the service endpoint of the laboratory, the doctor sends a request to obtain attributes $a{t}_1,\dots ,a{t}_n$ associated with $DID$ and provides his public key $ka$.
• The laboratory obtains the delegation from Hyperledger Fabric.
• The laboratory obtains the public key $kb$ associated with $DID$ from Indy and checks that the delegation obtained in the previous step is valid (signed using the private key associated with $kb$) and appropriate (it contains the key $ka$).
• The laboratory obtains the identity B of the patient associated with $DID$, searches for his attributes, and provides them to the doctor encrypted by his public key $ka$ as shown in

  Table 8. EHR protection.

  	During transmission (Provider to Patient)	Wallet	During transmission (Patient to Consumer)
  EHR protection	public key of Patient	public key of Patient	public key of Consumer

  . Please notice that, for efficiency reasons, public keys are not usually used to encrypt data except keys and hashes. So, encrypting EHR record R with a public key $k_a$ implicitly means that ${\left\{R\right\}}_k,{\left\{k\right\}}_{k_a}$ where k is a random private key.

The updated solution has the features given in

Table 9. Features of the Architecture Based of Hyperledger Indy and Fabric.

	Features	Patient Controls Access to His EHR	Anonymous Healthcare Service	EHR-Availability	EHR-Confidentiality	EHR-Integrity	EHR-Access Control Delegation	EHR-Zero-Knowledge Proof	EHR-Emergency Access	Scalability	Interoperability	Remote Health Service
Approach
Indy + Fabric EHRs		✓	✓	+-	+-	+-	✓	✓	✓	✓	✓	✓

✓ means that the approach given in the line has the feature given in the corresponding column. +- means that this feature is not always present; it depends on the provider-side security level. An empty case means that the proposed approach has not the feature given in the corresponding column. ✓: The red color for the check mark indicates that this feature is provided by this approach but it is not the case for those presented in the state of the art (see Section 6).

.

4.4. Module I: Increase Integrity, Availability and Confidentiality by Using IPFS and Fabric

In the previous solution, the EHRs records were stored in the healthcare provider’s local database. This means that the integrity, confidentiality, and availability of these EHRs depend on the provider side’s security level, who is continuously under cyberattack. To improve the protection of EHRs, healthcare providers can save them in a distributed database, such as the Interplanetary File System (IPFS) as shown in Table 5. EHRs provided by a laboratory with a public key $k_l$ are saved in IPFS as a file F containing ${\left\{EHR\right\}}_k,{\left\{k\right\}}_{k_l}$, where k is a random symmetric key. If we also want to give access to users with public keys $p{k}_1,\dots ,p{k}_n$, then we save a file F containing ${\left\{EHR\right\}}_k,{\left\{k\right\}}_{k_l},{\left\{k\right\}}_{p{k}_1},\dots ,{\left\{k\right\}}_{p{k}_n}$. This transparent protection technique gives us more confidence that the EHR confidentiality is appropriately protected. Additionally, IPFS provides good availability since it is a distributed database with sufficient redundancy, allowing access to files even if some storage nodes become offline. Moreover, to avoid the doctor having to directly contact the laboratory to obtain the address of the file F containing the EHRs of a patient identified by $DID$, we save $(DID,H(F\left)\right)$ in Hyperledger Fabric. Using Fabric for this purpose, we increase the integrity of F and its availability. The new architecture is as shown in Figure 4.

More precisely, the new solution works as follows:

• First, the patient visits a laboratory and receives some service that creates new healthcare attributes, $a{t}_1,\dots ,\dots ,a{t}_n$. At any moment later, he can send a request to associate a $DID$ to any parts of his attributes. He can also, at the same time or any moment later, send a delegation ${\left\{EHR\right\}}_k,{\left\{k\right\}}_{k_l},{\left\{k\right\}}_{p{k}_1},\dots ,{\left\{k\right\}}_{p{k}_n}$ to the laboratory. If the patient wants to give new principal access in the future, he can send a new delegation to the laboratory, and a new entry will be added in the IPFS, or we update the previous one.
  Notice also that we can handle the delegation as in the previous architecture, but with IPFS, we can immediately concretize it by giving access to the keys protecting the EHRs to all the authorized principals.
• The laboratory checks the patient’s identity and verifies that he owns the public key $kb$ associated with the $DID$.
• The laboratory adds to Indy a certificate linking $DID$ to $kb$.
• The laboratory creates the file F containing the requested attributes encrypted with its key and all the keys given within the delegation and saves it in the IPFS.
• The laboratory adds to Fabric a certificate linking $DID$ to $H\left(F\right)$ ($H\left(F\right)$ is the address of F in the IPFS).
• The patient contacts the doctor Alice and asks for a healthcare service and provides the $DID$ associated with his attributes that he wants to share with her.
• Alice obtains the public key $kb$ associated with $DID$ from Hyperledger Indy.
• The doctor asks the patient to prove that he owns the public key $kb$.
• The doctor obtains $H\left(F\right)$ associated with $DID$ from Hyperledger Fabric.
• The doctor obtians the file F with the address $H\left(F\right)$ from IPFS.
• The doctor uses her public key to decrypt the EHRs of the patient.

The updated solution has the features given by

Table 10. Features of the architecture based on Indy, Fabric and IPFS.

	Features	Patient Controls Access to His EHR	Anonymous Healthcare Service	EHR-Availability	EHR-Confidentiality	EHR-Integrity	EHR-Access Control Delegation	EHR-Zero-Knowledge Proof	EHR-Emergency Access	Scalability	Interoperability	Remote Health Service
Approach
Indy + Fabric + IPFS EHRs		✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

✓ means that the approach given in the line has the feature given in the corresponding column. +- means that this feature is not always present; it depends on the provider-side security level. An empty case means that the proposed approach has not the feature given in the corresponding column. ✓: The red color for the check mark indicates that this approach provides this feature, but it is not the case for those presented in the state of the art (see Section 6).

:

Please notice that neither the blockchain nor the IPFS allow the modification of EHRs. This useful property allows to keep track of the healthcare history of the patient. If the value of any health attribute is changed, a new record is added to IPFS.

The difference features supported by the proposed architectures are summarized in

Table 11. Differences between the proposed architectures.

	Features	EHR-Availability	EHR-Confidentiality	EHR-Integrity	Delegation	EHRs-Location	Delegation Location
Approach
Indy		+-	+-	+-		Patient’s wallet
Indy + Fabric		+-	+-	+-	✓	Patient’s wallet	Fabric
Indy + Fabric + IPFS		✓	✓	✓	✓	IPFS	Fabric

✓ means that the approach given in the line has the feature given in the corresponding column. +- means that this feature is not always present, it depends on the provider-side security level. An empty case means that the proposed approach has not the feature given in the corresponding column.

:

Table 12. Computations performed in the three proposed architectures (Indy, Indy + Fabric and Indy + Fabric + IPFS).

		Step	1	2	3	4	5	6	7	8	9	10	11
	Computation
Patient	Hash		0,0,1		1,1,1	0,1,0	0,1,0	1,0,0		0,1,0	0,0,1
	Signature or Private Key Encryption		0,0,1	0,1,1		0,1,0		1,1,0		0,0,1
	Signature Verification or Public key Encryption				1,0,0
	Symmetric Key Encryption/ Decryption
	Key Generation		1,1,0
	Random Number Generation		1,1,0
Laboratory	Hash		1,0,1	1,1,1	1,1,1		0,0,1
	Signature or Private Key Encryption			1,0,0	0,1,1		0,0,1						0,1,0
	Signature Verification or Public key Encryption		1,0,1	0,0,1		0,0,n					0,1,0
	Symmetric Key Encryption/ Decryption					0,0,1
	Key Generation
	Random Number Generation			1,1,0
Doctor	Hash					1,0,0	1,0,0	1,1,0	0,1,1	0,0,1	0,0,1		0,1,1
	Signature or Private Key Encryption											0,0,1
	Signature Verification or Public key Encryption					1,0,0	1,0,0	1,1,0	0,1,1	0,0,1	0,0,1		0,1,0
	Symmetric Key Encryption/ Decryption											0,0,1
	Key Generation
	Random Number Generation							1,0,0	0,1,0	0,0,1

resumes the main computations (hash, signature, signature verification, encryption, pair key generation, and random number generation) performed by the different actors for the three proposed architectures. It shows three values (blue, red and green) corresponding to the three proposed architectures (Indy, Indy + Fabric, Indy + Fabric + IPFS). When the values are absent, it is implicitly means that we have 0,0,0.

4.5. Handling Emergency Access

Different techniques can be used to handle emergencies:

• The decentralized identifier (DID) used in Indy is a W3C standard [30]. The main information in a DID record is the DID number and its owner’s public key. However, it may contain many other information useful for different contexts. For example, we find the authentication protocols that the owner can use with verifiers. Additionally, the DID record may contain delegation information giving other public keys of other subjects that can act on behalf of the owner and can be used for emergency access. In addition, the DID record is designed to be extensible so that we can add other fields useful for our specific contexts. In particular, we can add fields for the contact information related to delegated people for emergency; we gave their public keys in the delegation field. Another interesting feature provided by the DID is the ability to specify different verification and authentication methods. We can, for example, use a threshold signature. In this case, we can specify n keys in the delegation part, and require that at least k of them need to sign a challenge to able to behave on behalf of the owner. Using this mechanism, it is even possible to revoke a key according to the owner requirement.
• We can simply use the secret splinting technique to achieve this goal. The idea is as follows: To be able to act on behalf of Bob during an emergency, trustees need to know the DID of the vital attributes and the private key $k_b^{-1}$ associated to it. However, Bob does not want to give $k_b^{-1}$ to a particular trustee, but he allows any subgroup of trustees, with a predefined size, to reveal this private key. To this end, we can use the threshold cryptography (also called secret splitting) like [31]: the key $k_b^{-1}$ is encrypted by a random secret key k that can be revealed only by a group of trustees with the appropriate size. A common way to achieve this goal is to generate a random polynomial $P\left(x\right)$ of degree $l-1$, where $k=P\left(0\right)$, then we generate n points in the polynomial. Every trustee receives only one point on the polynomial. In this case, we are sure that at least l users are needed to rebuild the polynomial and find the value of $k=P\left(0\right)$ using the famous Lagrange equations [32].
  Of course, hospitals should know the contact of the trustees of Bob. For this reason, Bob needs to register them somewhere (e.g., hospital information systems) so that they will be found and contacted quickly. It will also be a good idea that hospitals are one of the trustees. Obviously, the emergency procedure (finding trustees, contacting them, recovering the key, and revealing vital attributes) should be automated so as to not waste a precious second.

4.6. Module II: Webauthn for More Security

In the previous architectures, the patient needs to protect his private keys appropriately in his computer or smartphone. However, this computer or smartphone can be infected by spyware that can steal these keys. To eliminate this risk, we can adapt Webauthn [33] or Fido U2F [26] to use an external USB security token that holds all the patient’s private keys and performs all the required cryptographic operations.

5. Prototype: A Proof of Concepts

As a proof of concept, we implemented a prototype of our health framework using Ubuntu 18.04.6 LTS (Bionic Beaver), Hyperledger Fabric 2.3.1, and Hyperledger Indy. Some screenshots are given by Figure 5, Figure 6, Figure 7, Figure 8, Figure 9, Figure 10 and Figure 11 to better clarify the idea.

5.1. EHR Based on the Hyper-Ledger Indy

We started by implementing the solution that manages EHRs based on Hyperledger Indy as summarized in Figure 2 and detailed in Section 4.2. Here are the various interfaces of the prototype involved during the different steps of the approach.

Suppose that patient Bob visits a laboratory L for the first time to receive some medical analysis. Usually, after his visit, a new record is created containing an association between the Bob public key and his set of medical attributes. Bob is not requested to provide his name; he can stay anonymous by only proving that he owns the private key associated with his provided public one. This verification is conducted using the protocol of Table 4. At the end of this visit, the local database of laboratory L is updated by the following entry, where $v_i$ is the value of the attribute $a_i$. The public key $k{b}_0$ will be an identifier of the patient Bob in laboratory L. It is not necessarily unique and can change from one visit to another.

PUBLIC-KEY	Date	Attribute ${\mathit{a}}_{\mathbf{1}}$	…	Attribute ${\mathit{a}}_{\mathit{n}}$
⋮	⋮	⋮	⋮	⋮
$k{b}_0$	1 January 2023	$v_1$	…	$v_n$

Similarly, Bob saves an association between his keys and the laboratory name in his secure local wallet. His wallet will be updated using the following entry:

Healthcare-Provider	PUBLIC-KEY	PRIVATE-KEY	Date	Attributes
⋮	⋮	⋮	⋮	⋮
L	$k{b}_0$	$k{b}_0^{-1}$	1 January 2023	$a_1,\dots ,a_n$

Now suppose that Bob visits doctor Alice, and he wants to show her some of his attributes provided by laboratory L:

• Bob sends a request to the laboratory to ask for a subset of attributes in $a_1,\dots ,a_n$ that are associated with $k{b}_0$. This request should contain the name of the attributes, his owner ($k{b}_0$), a fresh public key $kb$, and fresh random DID as shown in Figure 5. First, the laboratory checks the identity of Bob by asking him to prove that he owns public key $k{b}_0$ using the protocol of Table 4. Then, the laboratory asks Bob to prove that he is also the owner of public key $kb$ using the protocol of Table 4.
• The laboratory creates a certificate attesting that DID belongs to the owner of $kb$ and saves it in the hyper-ledger Indy as shown in Figure 6.
• Then, the laboratory creates a signed document (patient credentials) for Bob containing the DID and the requested attributes with their values. After that, the laboratory sends these credentials to Bob, who saves them in his wallet as shown in Figure 7.
• Patient Bob forwards the credential containing the attributes and their value to Alice.
• Then, doctor Alice accepts Bob’s invitation as shown in Figure 8 and obtains the public key Kb associated with DID from the hyper-ledger Indy.
• Alice requests Bob to prove that he is the owner of kb as shown in Figure 9. This proof is performed using the challenge–response protocol shown in Table 4.

5.2. EHR Based on Indy and Fabric

Hereafter, we implement the solution of Section 4.3, Figure 3, that delegates access control on EHRs based on Fabric. As in the previous case, during the first visit, Bob registers himself in the laboratory as the owner of some public key kb. He also creates a connection between the laboratory name and this public key in his local wallet.

• Bob contacts the laboratory as the patient known by kb, asks this laboratory to attest that he is the owner of the pair ($DID$, $kb$) as shown in Figure 6. The laboratory asks Bob to prove that he is the owner of kb using the challenge–response protocol shown by Table 4.
• The laboratory certifies the link between $DID$ and $kb$ and saves it in Hyperledger Indy as shown in Figure 6.
• Bob can add the delegation related to his attributes provided by the laboratory to Hyperledger Fabric as shown in Figure 10.
• Bob visits doctor Alice and provides her with the $DID$ and the list of attributes $a{t}_1,\dots ,a{t}_n$ that she can obtain from the laboratory as shown in Figure 11.
• Alice obtains the public key $kb$ associated with $DID$ from Indy as well as the service endpoint of the trusted provider that certifies this link.
• Using the public key $kb$, Alice asks Bob to prove that he is its owner using the challenge–response protocol given by Table 4.
• Using the service endpoint of the laboratory, Bob sends a request to obtain the attributes $a{t}_1,\dots ,a{t}_n$ associated with $DID$ and provides his public key $kb$.
• The laboratory obtains the delegation from Hyperledger Fabric as shown in Figure 10.
• The laboratory obtains the public key $kb$ associated with $DID$ from Indy as shown in Figure 6 and checks that the delegation obtained in the previous step is valid (it is signed using the private key associated with $kb$) and appropriate (it contains the key $kb$).
• The laboratory obtains the identity kb0 of the patient associated with $DID$, searches for his attributes, and provides them to the doctor encrypted by his public key $kb$.

6. Discussion

The main contribution of this paper is a modular architecture for EHRS. The core of this architecture is Hyperledger Indy, which is specially designed for the self-sovereign identity (SSI), where individuals have full control of their digital identities (a set of attributes that includes medical ones). Indy intrinsically provides many interesting features for EHR management, such as the following:

• No one can access to healthcare attributes without the consent of their owners.
• Patients can remotely prove that they are the owners of their EHRs.
• Patients can remotely prove, using zero-knowledge proof (ZKP), that a part of their healthcare attributes respects some properties without revealing their values (e.g., blood pressure is less than 130 mm Hg).
• Patients can hide some attributes in an EHR while revealing others.

In addition, the initial architecture is upgraded with Fabric to allow access control delegation. This second Hyperledger is used for the storage of the patient’s access control policies specified in the ABAC style. The delegation usually simplifies the access control by reducing the intervention of patients. Using Fabric as a generic Hyperledger provides the availability, the integrity and the traceability of access control policies.

Finally, we upgraded the architecture by adding IPFS that can play the role of wallets for the patients and increase the availability, the integrity and the traceability of the patients’ EHRs.

Table 13. Evaluation of related work and the proposed solution.

	Features	Full Patient Control over Their EHRs	Anonymous Healthcare Service	EHR-Availability	EHR-Confidentiality	EHR-Integrity	EHR-Access Control Delegation	EHR-Zero-Knowledge Proof	EHR-Emergency Access	Scalability	Interoperability	Remote Health Service
Approach
Sun et al. [5]				✓	✓	✓
Kumarn et al. [6]				✓	✓	✓
Khatoo [7]				+-	+-	+-
Nguyen et al. [8]				✓	✓	✓
Shen et al. [9]				+-	+-	✓
Niu et al. [10]				+-	✓	✓
Shahnaz et al. [11]				✓	✓	✓				✓
Kim et al. [12]				✓	✓	✓
Dagher et al. [13]				+-	+-	✓					✓
Liu et al. [15]				+-	+-	✓
Al Omar et al. [16]				✓	✓	✓
Dubovitskaya et al. [17]				✓	+-	+-
Liang et al. [18]				+-	+-	✓				✓
Xia et al. [19]				+-	+-	✓
Azaria et al. [20]				+-	✓	✓					✓
Yue et al. [21]				✓	✓	✓
Fan et al. [14]				+-	+-	+-
Proposed Approach (Indy +Fabric + IPFS)		✓	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓

✓ means that the approach given in the line has the feature of the corresponding column. +- means that this feature is not always present, it depends on the provider-side security level. An empty case means that the proposed approach has not the feature of the corresponding column.

evaluates the proposed approach and other related works according to the previous criteria, including anonymous healthcare service, availability, integrity, confidentiality, access control delegation, zero-knowledge proof (ZKP), emergency access to EHRS, scalability, interoperability, and remote health service.

• Full patient control over their EHRs: Any access to any EHR attribute by the doctor at step 10 of Figure 4 requires prior patient delegation in step 5.
• Anonymous Healthcare Service: Patients can register anonymously using DIDs and later prove ownership of any DID attached to their EHR.
• EHR-Availability: EHRs are stored in IPFS which inherently ensures availability since data are duplicated and decentralized.
• EHR-Confidentiality: EHRs are encrypted in step 4 of Figure 4 using public keys of authorized third parties only.
• EHR-Integrity: Since EHRs are stored in IPFS which addresses files by their hashes, any modification in a file renders the hash invalid.
• EHR-Access Control Delegation: Step 2 in Figure 4 allows patients to delegate any attribute of their EHRs to any third party
• EHR-Zero-Knowledge Proof: This feature is inherently provided by the Hyperledger Indy. Doctors cannot reveal any other information relating to the patients, except for the attributes that have been deliberately provided to them.
• EHR-Emergency Access: Examples of techniques that can be used to manage access to EHRs in an emergency were discussed in Section 4.5.
• Scalability: The most important characteristics affecting the scalability of the proposed architecture are storage and transaction speed.
  Transaction speed is usually addressed by selecting a Hyperledger using a fast consensus algorithm. Fabric uses the KAFKA-consensus algorithm [34] while Indy uses Byzantine Redundant Fault Tolerance (RBFT) [35]. As noted in [36], both are based on authorized voting and offer good speed. For example, according to the Fabric official website [25], the supported transaction speed is 3000 transactions per second. It is a fast blockchain compared to Bitcoin (maximum of 7 transactions per second) or Ethereum (45 transactions per second). For comparison, according to [37], Visa handles 1700 transactions per second. Regarding Indy, the supported transaction speed, according to [38], is 100 transactions per second.
  To address the storage scalability issue, most blockchain and Hyperledger use both online and offline storage. Transactions are stored offline, where their hashes are stored online and shared among peers. Other techniques, including vertical and horizontal scaling, are also used. For IPFS, for example, more nodes (servers) are added (vertical scaling) to give more storage to the overall file system before reaching its limit. The same idea applies to nodes used for offline storage with Hyperledgers. Another possible expansion can be achieved by adding more power and memory to existing nodes, which is also useful for improving the storage scalability of IPFS, Indy, and Fabric.
• Interoperability: Using an open, planetary file system, such as IPFS and a public Hyperledger such as Indy makes the solution more interoperable. Fabric could also be made public.
• Remote Health Service: The proposed solution allows patients to remotely prove their attributes, thanks to Indy, which is essential to open the door to remote healthcare services.

7. Conclusions

This paper proposes a modular framework called HealthBlock for collaborative sharing of EHRs based on blockchain. The solution is mainly based on Hyperledger Indy providing a self-sovereign identity (SSI) to allow patients to have full control of their EHRs, scalability, interoperability, anonymous healthcare service. Additionally, we use Hyperledger Fabric for access control management and zero-knowledge proof of EHRs and use IPFS to increase availability, confidentiality, and integrity. We can adapt Webauthn or Fido U2F to use an external USB security token that holds all the patient’s private keys and performs all the required cryptographic operations to allow the patient to protect his private keys in his computer or his smartphone.