Fully Decentralized Multi-Party Consent Management for Secure Sharing of Patient Health Records

Patients are becoming aware of the importance of taking secure control and managing access over their medical data, thereby leading to the rise in the adoption of personal health record (PHR) systems. However, today’s PHR systems fall short in providing secure and trustable data sharing and access facilities to patients when they are in emergency situations or temporarily incapacitated. Also, the existing PHR systems are centralized and vulnerable to the single point of failure problem. Integrating PHR systems with blockchain technology can help to overcome such limitations. In this paper, we propose a blockchain-based PHR architecture that employs smart contracts to implement multi-party authorization (MPA) and threshold cryptographic schemes to automate secure and trustable medical data sharing and access in PHR systems. Moreover, we mitigate the limited storage and computation capabilities of blockchain by using InterPlanetary File System (IPFS) storage and reputation-governed trusted oracles into the proposed architecture. MPA and threshold cryptographic schemes allow the patient to split and share a secret key with a set of trusted parties, such as the healthcare regulatory agency, guardians, and hospitals, in such a way that they can collectively decide on sharing medical data on behalf of patients. We present algorithms along with their full smart contract function implementation details. We evaluate the robustness and performance of our solution by performing correctness veriﬁcation and cost analysis. Furthermore, we evaluate the proposed approach in terms of security, generalization, and limitation aspects to ﬁnd out its feasibility and practicality. We make our smart contract code publicly available on GitHub.


I. INTRODUCTION
A personal health record (PHR) is the set of a patient's medical data, collected from multiple medical institutions (MIs), consumer health devices, and patient-gathered medical data (PGHD). Considering how the engagement of patients with their medical data leads to more positive healthcare experience, more patients are becoming interested in taking control over their medical data [1,2]. For a PHR system to be viable, it needs to be patient-centered, which requires that the contents of the health records are never accessed, viewed, or modified by any entity other than the patient, unless given explicit access rights that are secure, traceable, and auditable. Several enterprise solutions, such as Microsoft HealthVault, Google Health, and Apple Health, began to surface and gain popularity as PHR platforms [3]. However, due to their centralized nature, such solutions cannot be trusted to safely store patient data or to never use it without user consent. Furthermore, in the light of increasing security attacks, centralized medical data services are becoming more susceptible to security attacks and data hacks [4].
Blockchain is a decentralized technology that can be used as the foundation of a trustful and immutable system. The potential of blockchain and smart contracts have been explored and tested in various domains in terms of delivery assurance of digital and physical assets, incentive management for self-organizing networks, healthcare data management, and soybean traceability in the agricultural supply chain [5,6,7,8,9]. Utilizing a blockchain-based architecture in a PHR system, provides transparency, security, and provenance, and auditable features. Choosing the optimal blockchain architecture type, such as public, private, or consortium, depends on the requirements and goals to be met. In our previous work [10], we proposed a blockchain-based patient-centered PHR management system. Our approach integrated several other protocols and systems, such as InterPlanetary File System (IPFS), reputation-governed trusted oracles (RGTO), and proxy re-encryption (PRE) into the blockchain. IPFS is a peer-to-peer decentralized storage platform that provides the means to indirectly store large data off-chain and mitigating the storage drawbacks of blockchain. RGTO is a set of public computation nodes that compete to process a task, with a reputation system that punishes malicious actions and rewards virtue. The trusted oracles are utilized to execute resourceintensive tasks, which blockchain is too slow to perform. For example, fetching files from IPFS and cryptography operations, such as PRE cannot be done efficiently on-chain. PRE is a mechanism that atomically -with no middle steps -transforms the encryption state of a certain file from one key to another, provided a re-encryption key created by the original file owner.
A practical PHR management system must give the patient the choice to give partial or full access rights to other entities, such as doctors, nurses, relatives, or institutions. Moreover, the system should be able to decide whether or not to automatically authorize future access rights to entities chosen by the patient. For example, the patient can set their PHR such that in a case of emergency, if two relatives and a doctor request access to the medical documents, their requests will be automatically granted. In addition to that, the health records of an incapacitated patient, who could be in that medical state before or after creating their PHR profile, should be managed with utmost transparency and privacy, in such a way that ultimately keeps the full control rights with the patient. In this paper, we develop a PHR architecture that can efficiently deal with urgent emergencies. Note that our proposed solution works under the same rules for all types of patients and all kinds of use case scenarios.

A. RELATED WORK
A patient-centered dynamic access control scheme for PHRs has been proposed in [11]. The proposed scheme, based on individual authorizations to entities and public-key cryptography management, help to preserve the privacy of the patient PHR while allowing multiple users to get full access to the data. However, the solution cannot provide partial access to some of the patient records, in addition to being dependent on cloud services for storing the PHR data. The cloud dependency makes the solution architecture centralized, and therefore it is vulnerable to security attacks, such as the denial of service (DoS), thereby making the entire system unavailable.
In [12], the authors have proposed a blockchain-based framework to enable secure health data sharing between different healthcare providers. Another study conducted in [13] proposed a blockchain-based system named "MeDShare" to address the problem of medical data sharing in terms of data provenance and auditing. The MeDShare keeps the track record of all the entities along with their actions. All the actions performed on the MeDshare are recorded in a tamperproof manner. To deal with the privacy issues that exist in today's healthcare data storage and sharing systems, a decentralized and permissioned blockchain-based solution has been proposed in [14]. The proposed solution ensures privacy by enabling a separate channel communication scheme. It also enhances identity management using the membership service offered by the permissioned blockchain.
The study conducted in [15] proposed a more advanced attribute-based access control (ABAC) scheme that uses identity-related policies set by the users to securely share the electronic health records (EHR). The approach uses attribute authorities to validate user attributes without requiring the users to have prior registration in the network. The attribute authorities are trusted public entities, such as hospitals, which process the attribute verification on a centralized server, exposing the system to network security risks. Moreover, access control decisions based on user attributes are limited and do not allow time-based control of patient data sharing. On the other hand, another attribute-based approach presented by Li et al. [16] uses encryption to enforce the access control rules, in addition to providing multiple one-way privilege levels. The leveled privileges allow cascading the access rights, such that a higher-privileged entity can pass down partial access rights to a lower-privileged entity. As such, the patient can give their primary doctor full access rights to certain medical data, and the doctor can give partial rights to the nurse or another doctor. This approach takes away the patient-centered aspect of the healthcare system because the patient data access rights can be cascaded without patient consent. Moreover, the paper does not discuss a solution to emergency cases and incapacitated patients, where the patient data must be secured and shared with the smallest number of entities.
Another cloud-based access control scheme for EHRs was developed in [17]. The scheme uses ABAC in conjunction with extensible access control markup language (XACML) to offer a fine-grained and privacy-preserving EHR sharing. However, the design is centered around the requester (such as the doctor), and not the patient, which in patient-centered healthcare systems is supposed to own the data and have full control over it.
In [18], the authors introduced a blockchain-based solution for managing EHR data sharing. The study proposes a granular access authorization with support for flexible queries. Unlike previous cloud-oriented solutions, this approach does not mention the types of possible attributes required for decision making. In the same vein, the authors in [19] proposed a framework for secure interoperable and efficient access to health records while preserving patient privacy. However, the More recent research looked into building PHR management systems that have blockchain as their foundation rather than using it as an auxiliary technology. The authors in [20] designed a tamper-resistant and secure PHR system with support for granting and revoking access rights. In [21], the authors have leveraged ABAC to provide support for dynamic attributes in a blockchain-based EHR solution. Even though both solutions primarily use blockchain, they are not fully decentralized because of their partial use of cloud services or hospitals for storing public keys of entities and patient data. Furthermore, these solutions are not patientcentered, since the doctors have the privilege to override patient decisions.
EACMS is an emergency access control management system for blockchain-based PHRs, proposed by Rajput et al. [22]. This system is developed for emergency cases. How-ever, the study assumes that PHRs are stored in a cloud server that hinders its use in other architectures that store PHRs in a decentralized manner. On top of that, the solution does not have a mechanism for preventing abuse of emergency access.
An approach proposed by Battah et al. [23] showcases a blockchain-based architecture for multi-party authorization (MPA) and access control for encrypted data that is stored over distributed storage systems, such as IPFS. The design proposed in the paper is generic, which can be adapted into a variety of use cases; however, more refinement of the architecture is required to make it most suitable for the PHR management systems.
In summary, the existing healthcare solutions do not meet the necessary requirements for the PHR systems in terms of traceability, resiliency against security attacks, and delegating decision making to their trusted guardians in case of emergencies. In this paper, we propose a fully decentralized multi-party consent management system for accessing en- VOLUME 4, 2016 crypted PHR medical documents and delegating access permission rights to trusted entities. Our solution incorporates various technologies to ease off the weaknesses in current PHR systems. Note that our study is significantly different from our previous work [10] as it aims to solve completely different challenges and proposes a novel solution that is particularly designed using new techniques and flow of interactions among the entities. First, this paper defines a simple system structure that merges the patient and doctor into a single entity type, tightly integrates the reputation system with the oracles, and deploys a single one-time smart contract that keeps track of all interactions. On the other hand, in [10], the stakeholders are broken down without considering situations where the doctor entity could also be a patient in a different scenario, the oracles operate and interact with functions different than the ones that evaluate them, and the smart contracts are neither unified into a universal version nor broken down further such that each entity deploys its own. Second, all entities in this solution, except RGTOs, have their identities verified by the governing body that deploys the smart contract, therefore preventing cases of identity theft or repeated registrations, whereas [10] does not deal with such actions. Third, patients must have a secure and private mechanism to delegate the decision making regarding the sharing of medical documents to other trusted entities; however, the architecture proposed in [10] assumes the patients to be always available and legally able to grant or deny access permissions of the medical documents to doctors. Our key contributions are as follows: 1) We propose a fully decentralized blockchain-based multi-party consent management for patient-centered PHR systems to provide provenance of access log events in an immutable, auditable, trustful, and secure manner.
2) We develop smart contracts to implement MPA and threshold cryptographic schemes to automate secure and trustable medical data sharing and access in PHR systems even in cases of emergencies.
3) We integrate decentralized IPFS storage and trusted oracles to perform re-encryption into the proposed PHR architecture.

4)
We introduce a reputation-system layer to govern the entities that perform their processing off-chain, including the re-encryption oracles, doctors, and the regulatory agency that deploys the system.

5)
We develop algorithms that translate our proposed architecture and write smart contract functions and trigger events to implement the algorithm. The implementation code is made publicly available 1 .
6) We analyze the cost and security aspects of our solution and verify the correctness of our implementation, to know the limitations in a realistic deployment environment.
The remainder of the paper is organized as follows. In Section II, we present the proposed approach by explaining the different types of entities and smart contracts involved in 1 https://github.com/anon092020/PHR-MPA the solution. Section III presents the design, implementation, and evaluation details. In Section IV, we provide a detailed discussion on how the proposed solution meets the crucial requirements along with the security analysis and limitations of the study. We present conclusion in Section V.

II. PROPOSED BLOCKCHAIN-BASED SOLUTION
This section presents our proposed blockchain-based solution along with its full system component details, including Ethereum smart contracts, threshold cryptography, MPA, IPFS, RGTO, and PRE.

A. ETHEREUM AND SMART CONTRACTS
Ethereum is a public and open-source blockchain platform that provides a developer-friendly infrastructure for solutions that require full decentralization. Ethereum smart contracts are written in Solidity language. The smart contract code is executed by Ethereum virtual machines (EVMs), which are an execution environment that exists inside mining peer-topeer nodes. The mining nodes store mined Ethereum transactions in a chained sequence of blocks, in addition to mining new transactions by executing their smart contracts and reaching consensus using the Ethash proof-of-work (PoW) algorithm. In PoW, distributed nodes compete to solve a computationally-intensive problem, in exchange for Ether, which is the Ethereum cryptocurrency. The amount of Ether the winning nodes receive is correlated with the complexity of the smart contract code, which is measured in gas units [24,25]. The average gas price is measured typically in Gwei units, where 1 wei is 10 −18 Ether.
Although our solution keeps all patient data secure using public-key infrastructure (PKI) cryptography, certain sensitive files cannot be shared on the public Ethereum network due to privacy issues. In such cases, there is a need to use forks of Ethereum that are permissioned and private, such as Quorum and Hyperledger Besu [26,27].

B. THRESHOLD CRYPTOGRAPHY AND MULTI-PARTY AUTHORIZATION
Threshold cryptographic schemes are generally encryption and decryption protocols where more than one party can contribute to the operation [28], hence named as MPA. Threshold cryptography can be highly advantageous in decentralized systems that require the approval of m out of n entities for the cryptographic operation to succeed, where m ≤ n, n is the total number of entities involved in the encryption operation and m is the required number of entities for the decryption operation. The MPA comprises all the parties that generate, protect, or share the secret data. In our proposed architecture, these parties are the patient, the guardians (who could be the patient's relatives or trusted people), the hospital, and the regulatory agency.

C. INTERPLANETARY FILE SYSTEM
IPFS is a distributed storage solution that relies on public peer-to-peer nodes to maintain and share files. IPFS pos-sesses unique features, such as content-based addressing which makes the SHA-256 cryptographic hash of a certain file its identifier, InterPlanetary Name System (IPNS) for maintaining the same path for updated files, and version control system (VCS) as a protocol for file editing and updating. IPFS can help to overcome the storage limitations posed by blockchain systems by enabling them to store the hash of the file on-chain and using it as a pointer to the file [29].

D. REPUTATION-GOVERNED TRUSTED ORACLES
Oracles are used to make computation requests in exchange for monetary incentives. They are used to make up for the slow, limited, and expensive computation of EVMs; however, passing on all computations to a single oracle no longer makes the overall system architecture decentralized and trustful. In the proposed solution, we use proxy re-encryption servers/oracles to perform compute-intensive tasks because implementing them using the Ethereum-based smart contract can be very expensive [23].
Reputation-governed trusted oracles (RGTO) are constantly incentivized to act truthfully and quickly in two forms, the first is fueled by competition among the oracles to return the first and most accurate response to get a larger monetary payment, and the second relies on a reputation system that may potentially block untruthful oracles from receiving any request. In order to use oracles without forgoing the desired characteristics of blockchain, our smart contracts send the computation request to a large number of oracles and collect a sufficient number of results. Depending on the request, if it is possible to verify the result on-chain, the smart contract will accept the response of the quickest oracle, otherwise, the accepted responses are judged based on the majority or average of the results. A reputation system is a technique that helps to distinguish the truthful and untruthful oracles. Smart contracts determine what oracles to communicate with based on the reputation score of those oracles. Therefore, oracles are encouraged to maintain a high reputation score by returning accurate results as quickly as possible.

E. PROXY RE-ENCRYPTION
PRE is a cryptosystem scheme that enables the direct transformation of an encrypted file from one key to another without decrypting the file or sharing the private keys [30]. A simple example of using PRE between Alice and Bob is described in the following steps: 1) Encryption: Alice encrypts a secret message with her public key.
2) Re-encryption key generation: Alice uses her private key and Bob's public key to generate a re-encryption key and sends it to the PRE server.
3) Re-encryption: The PRE server transforms the secret message from Alice's public key to Bob's public key and sends the message to Bob. 4) Decryption: Bob decrypts the message using his private key, revealing the plaintext message.
In our solution PRE is used primarily to share patient medical documents with doctors, although not in a direct way as in the example above, because the medical document may have to be shared in emergency cases where the patient is not available to generate the re-encryption key.

F. OVERALL SYSTEM ARCHITECTURE
Our proposed system architecture is summarized in Figure 1 that shows all the entities that interact with each other in order to share a patient's medical document with a certain requesting doctor. Our solution requires all entities involved to be registered on the Ethereum blockchain network. Therefore, all of them have a unique Ethereum address (EA) and a private-public Ethereum key pair.
• Regulatory agency: A trusted governing body that could be the government or the department of health in the country. This entity deploys the main smart contract and is part of the MPA that approves the sharing of absent patient medical documents. The regulatory agency is also responsible for verifying the identities of any person or entity that registers into the network, whether that is the patient, guardian, doctor, hospital, oracle, or healthcare payer. The regulatory agency is ultimately managed by its employees through the decentralized application (DApp).
• Person: A general type of entity that by default is registered either as a patient or a guardian, depending on whether the entity is managed by the patient personally or by a trusted guardian or guardians. A patient can issue claims to become a guardian of other patients. Becoming a guardian enables the patient to be part of the MPA to approve the sharing of medical documents in cases where the patient is absent. Furthermore, patients can issue claims to registered as doctors, granting them permission to request patient medical documents. All claims issued by the patient must be verified by the MPA, more specifically, guardian claim requests are verified by receiving patient and regulatory agency approvals, whereas doctor claim requests are verified by receiving hospital and regulatory agency approvals. In addition to the Ethereum private-public key pair each person possesses, patients must have an IPFS key pair, with the private key is split and shared 50% (3 shares) with the regulatory agency and the remaining 50% (3 shares) are kept secret with the patient. Moreover, the patient will produce a unique key pair for each medical document uploaded to IPFS. The person handling this entity manages the PHR DApp either directly on a personal device or through a trusted thirdparty (TTP) service.
• Hospital: In addition to being the source of medical documents for patients, the primary responsibility of the hospital in this MPA scheme is to validate a person's claim of being a doctor, and to confirm the doctor's claim that a patient has an emergency admission to the hospital.
• Re-encryption RGTO: An RGTO node that fetches IPFS files, performs PRE process, and acts as an Ethereum Alarm Clock (EAC) for timeout functionality in Solidity [31]. The nodes race to perform PRE to transform the medical  document encryption from the patient to the doctor, after which, the winning node communicates with the doctor directly to transfer the re-encrypted medical document to the latter's local device.
• Insurance Company: Responsible for paying the decentralized storage and oracle nodes.
The regulatory agency deploys a universal regulatory agency smart contract (RASC) that manages all entities, and provides patients, guardians, and doctors with the ability to send transactions. Moreover, RASC performs reputation evaluation and maintenance of oracle nodes. 1) The patient generates a symmetric key, and encrypts the medical document using the key.

G. INTERACTIONS AND MESSAGE SEQUENCE
2) The patient generates medical document private-public key pair and encrypts the symmetric key using the medical document public key.
3) The patient generates an IPFS private-public key pair (only for the first medical document, will be used for all future medical documents), and encrypts the medical document private key using the IPFS public key.
4) The patient uses a threshold signature to split the IPFS private key into 6 shares (3 kept on local devices and 3 securely shared with the regulatory agency).
5) The patient uploads a bundle that consists of the encrypted medical document, the encrypted symmetric key, the encrypted medical document key, and a pseudo-random number to IPFS. Then the SHA-256 hash of the bundle is submitted to RASC.
6) The doctor requests the medical document, and optionally specifies whether the request is for an incapacitated patient or an emergency case.
7) The RASC informs the patient of a new request. If the request was for an absent patient the appropriate MPA will be informed as well. The MPA for an incapacitated patient requires the patient to be registered as such, validation of doctor credentials, and the approval of min( 0.7g , 5) guardians, where g is the total number of verified guardians. The MPA for an emergency case requires the confirmation of emergency admission from the hospital in concern and the validation of doctor credentials. 8) In case 1, the patient denies the request or the MPA requirements are not met within 1 hour, after which the RASC informs the doctor of denied access. The sequence terminates.
9) In case 2, the patient grants access then generates a reencryption key and sends it to RASC. The sequence continues from step 11. 10) In case 3, the MPA requirements are met within 1 hour. The RASC sends a reputation token to the patient to allow rating the doctor, then the regulatory agency nodes independently use their 3 shares and decrypt the medical document private key, which is then used by one of the nodes to generate a re-encryption key and sends it to RASC. The sequence continues from step 11. 11) The RASC informs the doctor of a granted access. 12) The RASC sends the medical document bundle hash and re-encryption key to a set of RGTOs.
13) The RGTOs request and receive the medical document bundle from IPFS, then get the random number from the IPFS bundle and send it privately to RASC. 14) The RASC evaluates the RGTOs, then updates the RGTO ratings and chooses the most reputable one. Then RASC sends a token to the winner RGTO and the doctor.
15) The doctor requests the re-encrypted medical document from the RGTO, which in computes and sends it to the doctor. 16) The doctor decrypts the symmetric key using the public key, then decrypts the medical document using the symmetric key. 17) Judging from the interaction with the RGTO, the doctor submits a rating to RASC, which in return updates the RGTO reputation.
Each of the steps of generating the symmetric key, IPFS key pair, and medical document key pair play an important role in the solution and provide an improvement to the design. Using the symmetric key rather than the patient's IPFS public key to encrypt the medical documents allow encrypting and uploading the medical document files, which are commonly large in size, only once. The file that is going to be re-encrypted by the PRE-running RGTOs is the encrypted symmetric key. The secret message that is split and shared with the trusted MPA entities is the medical document private key and not the symmetric key, this is because the PRE nodes eventually need the private key used in the symmetric key encryption for a successful re-encryption, however, revealing the Ethereum private key is prohibited, and therefore we use the health record private key.

III. IMPLEMENTATION
Considering the scope of our implementation, we defined the structure of 5 types of entities, 1) regulatory agency owner (RAO), 2) regulatory agency member (RAM), 3) hospital, 4) person, 5) RGTO. Figure 3 depicts the entities along with their attributes, methods, and relationships. All these entities interact with RASC, and therefore must have an Ethereum account. On top of that, the identities of these entities must be validated through the regulatory agency, with the exception of the RGTOs. RAM identities are verified at the time of registration since they are registered by the trusted RAO with the function registerRAM. The rest of the entities must issue claims and provide appropriate proof of identity documents to RAM employees off-chain as part of the regular identification system in the region. The registration claims are set by the smart contract functions corresponding to the different entities, which are registerPatient, registerDoctor, registerHospital, and registerRGTO.
A claim is a data structure that keeps track of the status of the claim, by storing a set of verifications and comparing them to a set of required verifications. The set of required verifications can be empty, in which case the verifications received will only be ensured to be recent. Algorithm 1 shows the implementation details of verifying, revoking, and checking the status of a claim. Several functions implement the claim verification process, including verifyPatient, verifyDoctor, verifyHospital, verifyGuardianship, verifyRequestByRAM, and verifyRequestByGuardian.
To verify a claim that is made, the algorithm learns whether the verification is new or repeated, and in case the claim requires specific verifiers it makes sure the new verification is one of those. New verifications are added to the set of verifiers, whereas repeated ones only update the date of verification. To revoke a claim verification, the algorithm simply iterates through the set of verifiers, then finds and deletes the verification if it was found. To check the overall verification state of a claim, the algorithm mainly tracks the number of recent verifications, both optional and required, then compares them with the minimum number of verifications needed.
Verified patients can make a claim that a certain verified person is their guardian, using the addGuardian function. The function takes the address of the guardian and adds it to a set of claims of guardianships, in which each claim can be only verified by the guardian, using the verifyGuardianship function. Patients can remove any person from being their guardian using the removeGuardian function. Our implementation of these functions is detailed in Algorithm 2.
Verified patients can also submit their medical documents to RASC while specifying the wanted number of RAMs or guardians. However, as seen in the implementation details in Algorithm 3, the actual needed number of RAMs and guardians is bounded between a range that is seen appropriate by the RAO, preventing the patient from mistakenly choosing zero or an impossible number of verifiers.
A verified doctor can request a specific medical document from the patient's record by submitting the patient address and the medical document's IPFS hash to the requestMDDoctor function shown in Algorithm 3. The doctor must also specify whether the request must be approved by the patient directly, or by the MPA, which consists of either RAMs and guardians for incapacitated patients, or RAMs and hospital in case of emergency.
As a result of the claim verifications having a validity period, a doctor's request can be used to receive a certain medical document for a specific period of time chosen by the patient. This allows patients to grant partial or full access to their health records for a limited period of time, even if they are no longer available to directly grant or deny access to their health records.
To proceed with the typical sequence of actions for a successful medical document sharing, the details of a verified

IV. DISCUSSIONS
In this section, we present our testing methodology, results, and discussions. Our testing of the implementation includes a correctness verification that ensures the relevant functions execute correctly according to the typical sequence of interactions. Additionally, we perform a cost analysis of all the developed algorithms and showcase our results in gas units and physical currency. Furthermore, we discuss various security aspects of our architecture design, highlight generalization possibilities and potentials, and describe open challenges and limitations.

A. CORRECTNESS VERIFICATION
To perform correctness verification of the smart contract, we compiled, deployed, and executed the code according to the typical sequence of actions as described in the previous section. Our testing involved 13 unique Ethereum accounts, as shown with their corresponding Ethereum addresses in Table 1. The compilation was made with Solidity compiler version 0.6.12 with code optimization enabled, and the deployment was on a JavaScript-based EVM running on a virtualized local Ethereum testnet. The major six phases involved in the life span of sharing medical documents are discussed below.

1) Deploying smart contract and registering entities:
The RAO deploys the RASC and registers all RAM entities. After that, the patient, guardians, and doctor register their accounts as a person. The RGTOs register their accounts as RGTOs. Once an entity is registered, it cannot register as a different type of entity, this design decision is made VOLUME 4, 2016 Require that msg.sender ∈ p.guardians Call verifyClaim on the guardianship claim to separate the roles and privileges of each type. Figure 4 shows the transaction result of RAM 1 trying to register as an RGTO.
2) Verifying identities: Accounts registered as a patient must have their identities verified before being allowed to perform any action using their accounts. RAMs verify the claims of each person. A person requires any two verifications by RAMs to be considered as a verified patient, these verifications expire after 1 year, requiring to be resubmitted. A doctor requires 4 RAM verifications, which expire every 3 years.
3) Adding and verifying guardians: The verified patient can add up to 5 guardians to his account. Guardianship claims must be verified by the relevant person. A guardianship claim must be renewed every 2 years. 4) Submitting and requesting medical documents: The patient uploads the encrypted medical documents to IPFS and submits the hash to RASC along with the desired number of RAMs and guardians needed to approve permitting a doctor request in cases of patient absence. The doctor can request the medical document of patients, and based on the request type, it can be forwarded to the MPAs. 5) Verifying requests: The required number of RAMs and guardians approve the medical document request made by  Figure 5 depicts. 6) Evaluating RGTOs and choosing the winner: The RGTOs respond to the RASC with a proof that they successfully fetched the file from IPFS. For each RGTO response, the RASC will evaluate whether the received responses are sufficient or not based on the minimum and maximum number of RGTOs specified by the doctor, and by a timeout of 1 hour. The minimum and maximum number of RGTOs the doctor can specify must fall within the range of 2 to 20. Setting a fixed limit on the number of responses caps the cost of the RGTO evaluation function, which is called when a sufficient number of RGTOs respond to the request. Further, after the doctor contacts the selected RGTO, they can submit their rating of the off-chain performance, as seen in Figure 6.  since higher gas prices mean higher incentives for miners. As evident in the table, the deployment of the RASC makes up the majority of the overall cost of the smart contract, however, it is worth considering that RASC is a one-time deployment smart contract. The remaining functions have much lower costs, ranging from just above $1.00 to around $10.00.

C. SECURITY ANALYSIS
Our solution enables patients to securely share their medical documents with doctors without compromising their privacy. Herein, we evaluate our solution against different security parameters.
• Authenticity: Our architecture is comprised two layers that protect against authentication attacks, which rely on the Ethereum address verification and physical identity authentication. All entities involved in interacting with the smart contracts are required to have an Ethereum account with a valid Ethereum address that is managed by an Ethereum wallet, therefore, unless an individual entity loses its exclusive possession of the private Ethereum key due to undefendable security attacks, such as social engineering, it can be trusted to be operated by its authentic owner, with zero chance of having the address of an entity be tampered with. On top of that, the presence of a regulatory agency that authenticates the identity of each component in the network protects against identity theft attacks, which is an important aspect because otherwise, entities can claim to be of a certain highprivilege category without consequences. However, even in the case of mistaken categorization of identity, our medical document sharing architecture protects against that by being a patient-centered solution that does not share any information unless the patient explicitly grants such access. On top of that, our implementation design prohibits the owner of one Ethereum address to operate multiple entities, thus eliminating a possible Sybil attack even further.
• Confidentiality and privacy: In our solution, no single information about any entity is made public, as all medical documents and secret metadata are stored privately on IPFS and the Ethereum network using symmetric and public-key encryption. Moreover, even the identities of patients are kept private, reducing the chances of data theft of a targeted PHR. Additionally, sharing the medical documents with doctors is done through PRE, which means no private key used in the encryption of data is disclosed, and no entity other than the patient and granted doctors can access any medical document. Even in the cases where the patient is having an emergency or in an incapacitated state, the sharing permissions goes through a distributed MPA that includes the regulatory agency, trusted guardians, and hospital, and the only condition for the patient medical documents to be shared without patient consent is for these parties to collaborate maliciously at the same time within the 1 hour request window. Our solution ensures the system is kept patient-centered, even with the existence of a trusted regulatory agency, by implementing all processing on decentralized smart contracts that cannot be self-destructed by the agency, and by allowing the patient to rate the MPA parties such that a non-consensual medical document sharing is never approved and repeated by taking away any MPA privileges on the patient data.
• Integrity and traceability: Using Ethereum as a foundation for our approach, allows the fundamental data flow to become fully traceable. Examples of such data include logs of requests to health records, token creation, and transmission, and reputation calculations, all along with their changes across time for full provenance ability.
• Availability: The proposed solution is based on a strict re-encryption scheme, which ensures confidentiality, as only the patient and the patient-chosen doctors can have access to the health records. Furthermore, health records are stored in a distributed and decentralized server, such as IPFS, which enables patients to offload storing medical files. Using the proposed approach, the patients do not need to trust any centralized third party entity to store the files. This ensures that the stored data is secure enough against well-knows attacks, such as distributed denial-of-service (DDoS).
• Non-repudiation: At every step in the span of any medical document sharing, starting from the deployment of the smart contract, and ending with evaluating the RGTOs, there is no way for any entity to deny any action it has made, whether that was on-chain or off-chain. Building our system from the ground up based on blockchain provides full traceability of all actions, because of logging all shreds of evidence immutably on the blockchain ledger, which means neither the sender nor the receiver of a certain message can deny sending or receiving it.

D. GENERALIZATION
Our proposed solution is tailored for the healthcare context in the United Arab Emirates; however, it can be generalized and scaled to other smaller or larger regions of different population sizes and healthcare hierarchy. Moreover, the design of our architecture does not put constraints on the mechanism the region verifies the identities of its people, but rather makes the mechanism more transparent and more enforceable. For example, the RAMs that verify a patient's identity can be employees of different government departments, such as the department of health and the department of digital authority.
A more generalized perspective of our solution can find it useful in completely different use cases outside the healthcare system. The patient in our architecture can be thought of as a user who uploads private data and provides data to the accepted requesters, in addition to allowing trusted parties to give the requester access to the data in case the user is absent. On top of that, thanks to using RGTOs as PRE nodes, regardless of the status of the user, the data is kept confidential all the time, and no third party, other than the accepted requester, can view it.

E. OPEN CHALLENGES
• Securing Ethereum private keys: Ethereum and DApps are new technologies that are still not used by any major solution that is deployed nationwide. Part of the reason is that a nationwide deployment would require demanding the general public to store the Ethereum private keys and passphrases securely and not sharing them with any other person. Considering the current state of failing to secure private information, combined with the spread of social engineering attacks, the users easily become the weakest link in the chain.
• Solution complexity: Our architecture integrates various techniques with blockchain to implement a decentralized solution for sharing encrypted medical documents even if the patient is absent. Although the result does achieve our goal, the solution with each added technique gets more complex, which makes it harder to deploy in the real world.
• Optimizing Solidity code: After writing and verifying the code of smart contracts, a necessary step of optimizing the code for the least amount of computation and data operations is crucial to avoid ending up with expensive smart contract functions. In Solidity, such optimizations can take a large portion of the development cycle, especially due to the scarcity of advanced debugging and optimization tools, unlike other more mature programming languages.
• Upgrading smart contracts: Another limitation of Ethereum smart contracts is the inability to upgrade them after deployment. Such a limitation prevents patching security vulnerabilities and software flaws, thereby putting users at security risks and several other unexpected problems.

V. CONCLUSION
In this paper, we have proposed a fully decentralized blockchain-based multi-party consent management solution for sharing and granting access to encrypted medical documents in a manner that is secure and trustworthy. Our approach maintains complete action traceability while providing an architecture for patients to authorize trusted entities to make access permission decisions on their behalf in case of emergencies. We implemented multi-party authorization and threshold cryptographic using blockchain technology to allow the patients to securely share and grant access to their medical documents along with sharing their secret keys. We integrated decentralized IPFS storage with our system architecture and introduced reputation-governed trusted oracles to mitigate the data and computation related limitations posed by the blockchain platform. We presented algorithms along with their full implementation details. Our correctness verification and cost analysis tests of the implementation verify the functionality and affordability of our system. Our code is made publicly available on GitHub, with a detailed description of how to reproduce our testing results. We perform security analysis and discuss how the proposed approach provides authenticity, confidentiality, integrity, availability, and non-repudiation.

VI. ACKNOWLEDGEMENT
This publication is based upon work supported by the Khalifa University of Science and Technology under Award No. CIRA-2019-001.