MEXchange: A Privacy-preserving Blockchain-based Framework for Health Information Exchange using Ring Signature and Stealth Address

Health information exchange (HIE) refers to the integrated management and secure sharing of health information among healthcare entities. HIE improves healthcare quality and streamline healthcare administrative work. These advantages have propelled health-care stakeholders to implement HIE. However, challenged by issues such as security, privacy, and costs, HIE is not widespread. Recent studies have suggested blockchain-based HIE for solving security and privacy issues. Unfortunately, existing blockchain-based HIE studies do not consider the privacy issues caused by analyzing senders and receivers of transactions in the blockchain. In this work, we suggest MEXchange, a novel blockchain-based privacypreserving HIE that prevents the privacy issue by obscuring the sender and concealing receiver addresses. We propose smart contracts and workflow that use ring signature and stealth address for blockchainbased HIE. Software components and implementation of MEXchange on the Ethereum private network are discussed. We evaluate MEXchange quantitatively by measuring the transaction latency and throughput of exchanging. Also, we evaluate MEXchange qualitatively using the requirements of the Office of National Coordinator for Health Information Technology (ONC). Moreover, we proceed threat modeling based on STRIDE. Finally, we compare MEXchange with Ancile, FHIRChain, Integrating the Healthcare Enterprise Cross-Enterprise Document Sharing (IHE XDS), and MedRec. The MEXchange lowers barriers to the application of blockchain-based HIE systems by mitigating privacy and security issues among healthcare stakeholders.


I. INTRODUCTION
Health information exchange (HIE) defines the integrated management and secure sharing of health information among healthcare entities [1]. The HIE improves the quality of health care, streamlines hospital care and administrative work, and enables diverse data analysis of research institutes [2]. These advantages have facilitated several research and developments geared to implement HIE. However, security and privacy issues impede this realization [3,4].
Healthcare stakeholders are attempting to address security and privacy issues in HIE through blockchain adoption [5,6,7,8,9,10,11,12,13,14,15,16]. To mention a few studies, Azaria et al. [5] sought to enhance interoperability by applying blockchain to health information exchange. Badr et al. [15] presented a secure healthcare data sharing method on blockchain considering both health information and IoT measured data. Patel et al. [16] utilized blockchain and cryptographic techniques to present a framework suitable and safe for medical image sharing.
The benefits of blockchain in HIE come in three aspects: integrity, availability, and trust. To falsify data in the blockchain, attackers alter all the data within the first and the latest block; thus, it is impossible to manipulate data in the blockchain [8]. Since blockchain reduces the number of centralized servers needed to implement HIE, new attack surfaces shrink [5]. Blockchain was invented assuming a trustless environment, verifying the trust of participants is not necessary, which increases the robustness of the overall system [6]. Several countries are examining the possibility of blockchain-based HIE. For instance, the U.S. announced that it will adopt blockchain to the management of electronic medical records (EMRs). China considers blockchain technology to strengthen security and facilitate HIE [17].
However, prior studies allow attackers to infer treatment patterns and hospital visit history by analyzing senders and receivers of transactions, resulting in de-anonymizing patients' identities. In finance, some studies identify participants in Bitcoin [18,19]. For example, Flender et al. derived a Bitcoin transaction graph and matched it with data obtained from web scraping. Consequently, they identified some participants in the Bitcoin network [18]. Prior blockchain-based HIE research also pointed out this issue. MedRec states that "even without the direct disclosure of a patient name, inference about who a particular patient is could be drawn from metadata of one Ethereum address with multiple others" [20]. Also, Ancile mentioned that blockchain analysis can reveal the visit frequency of a patient to a specific hospital and sensitive information such as date of birth, medical condition, and residential area [7].
This paper aims to propose and implement a novel blockchain-based privacy-preserving framework, MEXchange, as a solution to the inference problem through obscuring and concealing the sender and receiver addresses, respectively. Specifically, we adopt the ring signature and stealth address. Ring signature employs fake senders to obscure a genuine sender [21] while stealth address specifies a one-time address as the recipient and provides clues that allow the genuine receiver to confirm what was delivered to him [22]. We propose a system architecture, smart contracts, workflow, and software components for MEXchange. The system architecture shows the high-level view of MEXchange, which includes the role of players and interactions between the players and smart contracts. Also, we present generalized smart contracts to enable MEXchange implementation on any blockchain platforms that support smart contracts. The workflow outlines exchange steps and covers the detailed interaction with smart contracts in each step. The software components are suggested for MEXchange prototype implementation. Lastly, we implement MEXchange on Ethereum and evaluate it in quantitative and qualitative aspects. In the quantitative aspect, we measure the transaction latency and throughput. In the qualitative aspect, we evaluate MEXchange in eight dimension: authenticity, availability, confidentiality, ease of integrating new data providers, integrity, privacy, scalability, and transparency. Finally, we identify the threats in MEXchange through threat modeling based on STRIDE.
The remainder of the paper is organized as follows. Section II reviews related articles on blockchain-based HIE; Section III introduces the prior knowledge required to under-stand MEXchange; Section IV presents a system architecture, smart contracts, workflow, and software components. Furthermore, results of implementation and evaluation are described in Section V; Section VI compares MEXchange with other HIE systems; Finally, Section VII concludes this work.

II. RELATED WORKS
Recently, studies have combined blockchain with HIE to enhance security and privacy. Azaria et al. [5] proposed the first blockchain-based HIE approach, MedRec. Suppose that EMRs are stored in hospitals' private databases, MedRec suggested an incentive and access control mechanism for exchanging EMRs on using Ethereum. Furthermore, it designed smart contracts with interactions between healthcare entities and blockchain. Although pioneer to blockchain-based HIE research, MedRec does not include the measures to prevent security and privacy issues to arise with blockchain in HIE.
Several studies applied cryptographic techniques to blockchain-based HIE for improving security. FHIRChain [6] proposed a token-based access control mechanism that encrypts metadata with recipients' public keys to allow recipients to decrypt the metadata and obtain EMRs. The metadata is data needed to achieve health information, such as IP and PORT. FHIRChain analyzed the security requirements of the Office of National Coordinator for Health Information Technology (ONC) and reflected them in the system design. Liu et al. [23] proposed a secure access control mechanism BPDS to share EMRs using ciphertext-policy attribute-based encryption (CP-ABE). The CP-ABE employs attributes such as ID and name to encrypt and decrypt data. BPDS allows participants who hold correct attributes can decrypt metadata and access EMRs, which results in preventing unwanted data disclosure. Ancile [7] improves security through a proxy reencryption scheme that streamlines key sharing steps. This leads to reducing the possibility of key theft by decreasing the number of key shares. Moreover, Ancile designed smart contracts and workflow suitable for sharing EMRs with proxy re-encryption.
Alternatively, some researchers have strived to enhance security and privacy by limiting blockchain participants. Omar et al. [24] proposed MediBchain that employs a permissioned blockchain, which permits authorized users to participate in the blockchain. MediBchain uses private accessible units as intermediaries for storing health information in the blockchain. Similarly, data recipients receive health information via private access units and so, data disclosure does not happen unless the private accessible units are compromised. Zhang et al. [25] proposed the blockchain-based HIE that exploits private and consortium blockchain where an individual or organizations manage the blockchain participants. Private blockchain stores patients' health information securely, while consortium blockchain manages metadata for sharing.
Although Ancile and FHIRChain proposed the blockchainbased HIE approaches with cryptographic methods, the inference problem was not considered. Although they increase confidentiality by encrypting sensitive data. the inference problem remains because the sender and receiver are still publicly visible. Omar et al. and Zhang et al. limited participants to authorized users. However, attackers can deanonymize participants using senders and receivers in transactions when the authorized nodes are compromised. Thus, it is necessary to find a method that prevents the inference problem.

III. PRELIMINARIES
This section provides the necessary background information to understand MEXchange. First, we explain the smart contracts used for implementing business logic in the blockchain. Second, we describe the generation and verification of the ring signature to obscure the sender of a transaction. Finally, we explain how to create and verify the stealth address to hide the recipient.

A. SMART CONTRACTS
Smart contracts are programs for managing digital assets in a decentralized manner according to the business logic specified in the contracts [26]. They are deployed and executed through transactions [27]. Business owners who want to deploy smart contracts generate and broadcast transactions containing smart contracts to the blockchain network. The smart contracts deployment is complete when a block containing the transactions is attached to the blockchain. When executing smart contracts, business stakeholders input parameters in transactions and transfer them to the blockchain network. Then, blockchain participants execute smart contracts using the parameters and update variables. Upon deploying smart contracts, manipulating their contents is hardly possible. In this paper, we designed six smart contracts to share health information securely and prevent data falsification.

B. RING SIGNATURE
Ring signature employs fake senders not participating in a transaction to obscure a genuine sender while providing the receiver with clues used to verify the transaction. [21]. With the clues, the receiver can notice that a particular sender holds a private key corresponding to one of the public keys in the signature. Since most blockchain platforms adopt Elliptic Curve Cryptography (ECC), this paper employs an ECCbased ring signature method [28].
Suppose a sender s sends a ring-signed transaction with ring size n to a receiver, and other participants' public keys B are known in advance. The sender randomly selects the initial value k and generates an initial point T i as below: where x i and y i are coordinates of the point T i and · denotes the elliptic curve multiplication. The sender randomly selects u t where t = i+1, i+2, ..., n, 1, 2, ..., i−1. Subsequently, the sender calculates c t and T t (t = i+1, i+2, ..., n, 1, 2, ..., i−1 and t − 1 = n when t = 1) as below: where hash is the hash function. Then, c i and u i are derived as below: where d i is the private key of the sender and q is the order of the elliptic curve. The sender generates a transaction containing ring signature σ = (c 1 , u 1 , ..., u n , B 1 , ..., B n ) and sends it to the receiver. After receiving the transaction, the receiver verifies it using σ. First, the receiver calculates T t and c t+1 for all t (1 ≤ t ≤ n − 1) using equations (2) and (3). Second, the receiver derives T n and c 1 as below: Finally, the receiver checks whether the c 1 equals c 1 or not.
If the values are the same, the ring signature verification is completed.

C. STEALTH ADDRESS
Stealth address uses a one-time address to improve privacy by disconnecting a link between the sender and receiver of a transaction in a way that does not specify the recipient's address [22]. Although the sender's address is absent, the transaction contains clues that the recipient can figure out. The receiver finds transactions sent to him with the clues and private key. In the following, we explain the details of creating and verifying the stealth address. When sending a transaction to a receiver with stealth address, the sender selects a private key k randomly and calculates the corresponding public key K. The public key K is computed by: Using the public key B of the receiver, the sender derives a stealth address SA tx calculated by: Then, the sender creates a transaction including K and SA tx and sends it to the blockchain network. The receiver derives the stealth private, public key, and stealth address using the receiver's private key b. The stealth private key sP riv is driven by: Subsequently, the receiver calculate stealth public key sP ub as below: sP ub = sP riv · G Finally, the receiver calculates stealth address SA tx using If SA tx equals to SA tx , the receiver concludes that the transactions is transferred to him.

IV. METHODS
This section describes methods to design MEXchange, a system that utilizes ring signature and stealth address with blockchain-based HIE. A general over-view is presented, and then we explain smart contracts, workflow, and software components for MEXchange. Furthermore, we demonstrate how we implement the prototype of MEXchange and evaluate it.
A. MEXCHANGE OVERVIEW Figure 1 illustrates the MEXchange overview we devised to address the inference problem. In MEXchange, there are four players: certificate authority, hospitals, patients, and requestors. Certificate Authority authenticates new participants and records them in the blockchain. The hospitals manage health information in their databases and provide requestors health information. Patients grant access to the requestors and provide them the metadata received from the hospitals for exchanging health information. Requestors ask patients for access and request health information from the hospitals. We employ a private blockchain so that only authorized users can participate in MEXchange. Furthermore, we assume that the transaction fee is zero since we do not utilize public blockchain. To leverage the blockchain, we employ six smart contracts: access permit, access request, exchange log, information hash, participant, and ring verifier contracts. Access permit and request contracts govern access permission granted by patients and access requests from requestors respectively. Exchange log contract stores the history of exchange between the data providers and requestors for audit. Information hash contract stores the hash values of health information and metadata for data integrity. Also, it manages the encrypted metadata, stealth address, and ephemeral key to allow patients to recover their metadata. Participant contract manages the participants' identity data such as blockchain addresses and public keys. Finally, the ring verifier contract verifies the ring signature included in the access request.
We utilize ring signature and stealth address to enhance privacy. When asking for access permission from a patient, a requestor generates a transaction with fake senders and a receiver. The patient scans stealth addresses in transactions using the clues and finds the access request forwarded to him. Thus, the sender and receiver are not exposed to blockchain participants and this prevents the inference problem.

B. SMART CONTRACTS
We defined six smart contracts in aspects of variables and functions as shown in Figure 2. Each smart contract stores data in variables and manage them through functions. These six smart contracts consist of access permit, access request, exchange log, information hash, participant, and ring verifier contracts.

1) Access Permit Contract
Access Permit Contracts (APC) manages the access permission by patients. The APC contains five variables: · addrs ARC : the addresses of access request contracts · perID: the access permission ID · enc[accP erF orm] sym : the access permission form encrypted with a symmetric key. The access permission form contains the patient's address, the patient's signature, the requestor's address, health information ID, the address of the Information Hash Contract(IHC), and metadata, i.e., addr pat , sig pat , addr req , ID HI , addr IHC , metadata . The sig pat is used by the requestor and hospital to check whether the permission is from the intended patient. The patient generates the sig pat by signing a simple message consented on the MEXChange such as 'yes'. The requestor and hospital verify it using the patient's public key and the message.  · addr RV C : the address of the Ring Verifier Contract · addr AP C : the address of the Access Permit Contract · reqID: the access request ID · SA: stealth address generated using the patient's public key · ephemKey: the clue used to calculate stealth address with a symmetric key. The access request form consists of the requestor's signature, the addresses of the requestor, and the ID of health information, i.e., sig req , addr req , ID HI · enc[sym] pat : the symmetric key encrypted with the patient's public key · state: the state of access request such as 'None', 'permitted', and 'rejected' · perID: the ID of corresponding access permission in the APC The function storeAccReq stores reqID, SA, ephemKey, enc[sym] pat , enc[accReqF orm] sym in variables. Also, this function is only called by Ring Verifier Contract(RVC).

3) Exchange Log Contract
Exchange Log Contract (ELC) preserves logs (e.g., requestor's ID and timestamp) so that patients and hospitals can monitor exchanging. The ELC includes five variables: · addr hos : hospital's address that owns the ELC · ID HI : health information ID generated by the hospital's health information system · enc[log] sym : the log encrypted with a symmetric key · enc[sym] pat : the symmetric key encrypted with the patient's public key · enc[sym] hos : the symmetric key encrypted with the hospital's public key To be more specific about the ID HI , the health information reqID ← reqID + 1 6: state ← 'None' 7: perID ← N one 8: Store reqID, SA, ephemKey, enc[accReqF orm] sym , 9: enc[sym] pat , state, perID 10: Return reqID 11: else 12: Return -1 13: end if ID is provided to the patients after the patients are treated and health information is generated. Then, the patients can acquire exchange log for their health information using the ID later. The function storeLog allows the hospital to store the logs in the ELC. The hospital whose address matches with addr hos only store the log in the ELC.

4) Information Hash Contract
Information Hash Contract (IHC) is responsible for assuring the integrity of health information. To achieve integrity, the IHC holds four variables: VOLUME 4, 2016 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. state ← 'permitted' 10: else 11: Discard the access permission 12: end if · addr hos : the address of a hospital that owns the IHC · ID HI : the ID of health information · hash(meta): the hash of metadata used to verify the integrity of metadata · hash(HI): the hash of health information used to verify the integrity of health information The function storeHash allows hospitals to store the set of variables ID HI , hash(meta), and hash(HI) in this contract. This function is only invoked by the hospital whose address is addr hos .

5) Participant Contract
Participant Contract (PC) owned by the CA governs the participants' identity data to manage participants. The PC · addr CA : the address of CA · addr: the participant's address · pubkey: the participant's public key · addr: the participant's address · addr ARC : the address of ARC to which the patient belongs, which is used by requestors for requesting access The PC provides the function regP articipant to allow the CA to store the participants' data. Ring Verifier Contract (RVC), governed by CA, verifies the ring signature in the access request transactions. The RVC contains the address of the PC addr P C as a variable. The PC manages all participants who registered in MEXchange. Also, the PC is the only one smart contract deployed in the blockchain. Therefore, even if the RVC includes addr P C , the specific participants cannot be linked. The function ver-ifyRingSig is responsible for verifying the ring signature. After verification is complete, the RVC transfers the access requests to the ARC.  Invoke the storeAccReq of the ARC whose address equals to ARCaddr 4: end if

C. WORKFLOW
This section describes five workflows: participants registration, metadata preparation, access request, access permission, and health information sharing.

1) Participant registration workflow
Participant registration workflow authenticates users and registers them as participants of MEXchange. The procedure of this workflow is described below: · A user generates private key, public key, and address, i.e., privkey, pubkey, and addr · The user sends pubkey and addr to the CA with signature sig signed using the private key · The CA verifies the sig using the pubkey · The CA selects addr ARC to which the user will belong and store pubkey, addr, addr ARC in the PC using the function regP articipant · After the registration is complete, the CA delivers ID and addr ARC to the user

2) Metadata preparation workflow
In metadata preparation workflow, a hospital generates and provides metadata to a patient. Then, the patient receives the metadata and store it in the local database. The metadata is data needed to achieve health information such as IP, PORT, and database query. The detailed workflow proceeds as follows: · The hospital stores health information of treated patients in the local database · The hospital generates metadata and calculates hash values hash(meta), hash(HI) · The hospital stores ID HI , hash(meta), hash(HI) in the IHC using storeHash · The hospital provides the ID HI and metadata for the patient · The patient stores ID HI , metadata in the local database · For the ID HI and metadata recovery, the patient encrypts them with his public key. Then, the patient stores them in the blockchain. When the recovery, the patient searches the transaction that holds enc[ID HI ] pat and enc[metadata] pat , and decrypts them with his private key

3) Access request workflow
Access request workflow is the procedure that a requestor seeks permission to obtain health information from a patient as illustrated in Figure 3(a). We assumed that the requestors know the ID HI that they want to request through the patients and CA in advance. This workflow proceeds as follows: · The requestor selects n of participants' addresses and public keys randomly from the PC · The requestor retrieves the target patient's public key B and addr ARC from the PC · The requestor generates the ring signature sig ring = c 1 , u 1 , ..., u n , addr 1 , ..., addr n , ephemKey = k · G and SA = hash(hash(k · B) · G) where k is a random number · The requestor creates accReqForm containing the requestor's signature, requestor's ID, and the ID of health information, i.e., sig req , ID req , ID HI · Then, the accReqForm is encrypted with a symmetric key · The symmetric key is encrypted with the patient's public key · The requestor creates an access request transaction containing the sig ring , addr ARC , SA, ephemKey, enc[sym] pat , and enc[accReqF orm] sym as shown in Figure 4(a) · The requestor generates a one-time account and sends the access request transaction to the RVC with the sender as the one-time address · The RVC obtains the public keys using addresses in ring sig · The RVC verifies the sig ring using the verifyRingSig function · The RVC invokes the storeAccReq of the ARC whose address corresponds to addr ARC · The ARC checks whether the sender address is included in addrs ARC . Then, the ARC stores the access request Through the access permit workflow, a patient grants access to a requestor as shown in Figure 3(b). This workflow proceeds as follows: · The patient obtains the access requests from the ARC to which he belongs · The patient calculates stealth private key sP riv = hash(privkey · ephemKey) + privkey, public key sP ub = sP riv · G, and address SA = hash(sP ub). Then, the patient checks that SA equals SA for all access requests · If it equals, the patient decrypts enc[sym] pat with his private key and enc[accReqF orm] sym with the symmetric key. Then, the patient obtains sig req , ID req , ID HI · The patient retrieves the requestor's public key from the PC · The patient verifies the sig req using the requestor's public key · The patient retrieves the addr IHC and metadata that matches the ID HI and in the local database · The patient generates an access permission form ID pat , sig pat , ID req , ID HI , addr IHC Figure 4(b). Then, the patient signs the transaction with sP riv and sends it to his ARC (using the function transf erAccP er) · The ARC retrieves the SA corresponding to reqID and checks that the sender's address is the SA · The ARC invokes the function storeAccP er of APC as inputs enc[accP erF orm] sym , enc[sym] req , enc[sym] hos . If it returns perID, the ARC stores perID of the access request and the state as 'permitted'

5) Health information sharing workflow
In this workflow, as shown in Figure3(c), requestors ask for health information from hospitals, and hospitals provide the requested health information to the requestors after checking patients' permissions. This workflow proceeds as follows: · After noticing that the state of access request is changed, the requestor obtains perID in his access request from the ARC · Then, the requestor obtains enc[accP erF orm] sym and enc[sym] req from the APC corresponding to the perID · The requestor decrypts the enc[sym] req with his private key and enc[accP erF orm] sym with the symmetric key, and obtains addr pat , sig pat , ID HI , addr IHC , metadata · The requestor verifies the sig pat with the patient's public key · The requestor obtains hash(meta) and hash(HI) from the IHC whose address is addr IHC · Then, the requestor calculates and compares the hash value of metadata with hash(meta) · The requestor asks for health information to the hospital using the metadata while providing sig req , addr req ,, reqID, and k where k is the random number that was used to generate ephemKey in the access request workflow · Upon receiving the request, the hospital obtains the requestor's public key from the PC using addr req · The hospital verifies the sig req using the requestor's public key · The hospital checks whether the state of permission is permitted or not. If the state is 'permitted', the hospital obtains perID and SA from the ARC using reqID · The hospital retrieves enc[sym] hos and enc[accP erF orm] sym from the APC using the perID · Then, the hospital decrypts enc[sym] hos with the private key and enc[accP erF orm] sym with the symmetric key, and obtains addr pat , sig pat , addr req , ID HI , addr IHC , andmetadata · The hospital retrieves the patient's public key that matches with addr pat from the PC · The hospital verifies the sig pat using the public key · To prevent stealing and utilizing enc[accP erF orm], the hospital calculates SA using the patient's public key and k (SA = hash(hash(k · B)) · G + B where B is the public key of patient). Subsequently, the hospital checks whether the SA equals to SA retrieved from the the ARC · The hospital retrieves health information using ID HI and delivers it to the requestor · The hospital creates enc[log] sym , enc[sym] pat , enc[sym] hos and store them in the ELC using the function storeLog ( ) · Upon receiving health information, the requestor calculates the hash of health information · Then, the requestor compares the hash of health information with the hash(HI) obtained from the IHC

D. SOFTWARE COMPONENTS
MEXchange software components are structured into the presentation, business logic, and storage layers as depicted in Figure 5. The presentation layer consists of the user interface and controller for interacting with users directly. The controller forwards the user's request to the business logic layer and returns the results via the interface. The business logic layer connects the presentation layer with the storage layer. It consists of six components: blockchain, cipher, database, push, API manager, and scanner. The blockchain manager transmits transactions to the blockchain (e.g., access request and access permit transaction). The cipher manager encrypts data, and generates ring signature and stealth address. The database manager retrieves data in the local database. The push manager sends alarms to users. The API manager sends and receives requests to and from other participants such as CA and hospitals. The scanner finds access requests forwarded to the user through stealth address scanning. The storage layer manages the data required to operate MEXchange. It consists of the blockchain and local database. The blockchain contains six smart contracts and updates block data. The local databases store and manage private information such as health information, personal identity data.

E. IMPLEMENTATION
We implement MEXchange as a prototype based on the software components. The presentation layer is developed using HTML, CSS3, JavaScript.

F. EVALUATION
We evaluate MEXchange in terms of both quantitative and qualitative aspects. In quantitative evaluation, we investigate the transaction latency and transaction per second for access request, request scan, and access permission which are key processes for exchanging health information in terms of different number of transactions. We measure the transaction latency and transaction per second in the access request depending on the size of the ring signature (4, 8, and 12). Additionally, we compared the results of MEXchange with MedRec whose source code is available 1 for access request and permission. The reason for measuring only access request and permission is that MedRec does not utilize stealth address, so the request scan does not exist. We evaluate MedRec on a blockchain with the same configuration as MEXchange. We construct the private Ethereum blockchain using the PoW(Proof-of-Work) consensus algorithm for measurement. The configuration of the private network is shown in Table 1. The private blockchain consists of two machines. The first machine runs on a Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz, 32GB 2400 MHz DDR4 desktop. The second machine runs on an AMD Ryzen 5 3600X 6-Core Processor, 32GB 2667 MHz DDR4 desktop. In the qualitative aspect, we adopted the method that evaluates blockchain solutions using non-functional requirements and properties as shown in Figure 6 [26]. The non-functional requirements specify criteria rather than a specific behavior to judge the operation of a system. The non-functional properties are performance categories for technology that stem from the requirements. Based on the evaluation method, we extract non-functional requirements of the HIE system from a report written by ONC [1]. Then, we derive key non-functional properties such as confidentiality, integrity, and availability from the requirements. Then, we evaluate MEXchange using the key non-functional properties listed.

G. THREAT MODELING
We adopted the threat modeling method suggested by Howard and Lipner [29] to identify security vulnerabilities of MEXchange. They proposed nine threat model steps: 1) define use scenarios; 2) gather a list of external dependencies; 3) define security assumptions; 4) create external security notes; 5) create Data Flow Diagrams (DFD) of the application being modeled; 6) determine threat types; 7) identify the threats to the system; 8) determine risk; 9) plan mitigations. Among the steps, we focused on from step 5 to step 7. Therefore, we derived DFD for exchanging health  The schema for qualitative evaluation information in MEXchange. Subsequently, we determined threat types using STRIDE (Spoofing identity, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege) which is Microsoft's taxonomy. Finally, we identified the threats to MEXchange. Figure 7 shows the user interface of prototype implemented. Figure 7(a) shows that a requestor generates an access request transaction and sends it to a patient through the blockchain. The requestor inputs addr pat and ID HI in the interface. Then, the software generates ring signature, stealth address, and access request form and shows them through the interface. Figure 7(b) shows that the patient receives access requests delivered to him by alarm and permits access to his health information. When the patient clicks the permit buttion, the software generates access permission form and sends it to the blockchain.

B. QUANTITATIVE EVALUATION
We measure transaction latency and throughput for three major operations: access request, request scan, and access permission. Furthermore, we compare the results of MEXchange with MedRec. The evaluation results represent the average of five independent trials.
In access request, we measure the transaction latency for access requests to be stored in the ARC, i.e., time taken for verifyRingSig(), transferAccReq(), and storeAccReq(). Subsequently, we calculate the TPS using the transaction latency. Figures 8 and 9 show the results, respectively. The transaction latency tends to grow as the number of transactions increases. The TPS tends to decrease and then becomes stable as the number of concurrent transactions increases. Regarding the ring size, transaction latency increases and the TPS decreases as the ring size increases. This is because the number of operations needed for ring signature verification increases as the ring size becomes bigger. Compared to MedRec, access requests in MEXChange take a long time and handle fewer transactions per second. When the TPS becomes stable, MedRec's throughput is about 1.2, 4, and 8 times that of ring sizes 4, 8, and 12. The reason is that MEXChange requires additional computational time in verifying ring signature to improve privacy. Moreover, MEXchange encrypts sensitive data to enhance security. This increases the transaction size and reduces the number of transactions processed in one  In request scan measurement, we defined the transaction latency as the time taken to find access requests and derive sP riv using the ephemKey and SA contained in the access requests. Figure 10 and 11 show the results of transaction latency and TPS. In this result, the time taken tends to increase linearly as the number of transactions scanned increases, which yields an almost constant TPS. Furthermore, the access request scan time takes less time compared to access requests and access permission. This is because the scanning is done on the local machine, so no latency occurs during transaction propagation and processing.
In access permission measurement, the transaction latency is defined as the time taken to broadcast access permission transactions and store them in the APC, i.e., time taken for transferAccPer() and storeAccPer(). Figure 12 shows the transaction latency of access permission. Subsequently, we calculate the TPS using the measured transaction latency as shown in Figure 13. The transaction latency tends to grow as the number of transactions increases. In the TPS, the throughput of MEXchange and MedRec increases until the number of transactions is 200 and 300, respectively, and then decreases and becomes stable. This is because transactions are contained in one block until the number of transactions is 200 and 300, respectively. That is, although the processing time is almost the same, the number of transactions processed increases. Therefore, the throughput increases. After that, the number of blocks needed to process transactions increases, and throughput decreases and becomes stable. When the TPS is stable, the throughput of MEXchange is about 50% of MedRec. This is because MEXchange stores the data as encrypted in the blockchain, which increases the transaction size and lowers the number of transactions contained in one block.

C. QUALITATIVE EVALUATION
We extracted four key non-functional requirements and identified eight key non-functional properties from the requirements.
· Protect privacy and security in all aspects of interoperability and respect individual preferences. The requirement insists stakeholders propose effective protection for health information against problems arising from HIE to assure public trust that health information is safe and secure. Also, it is essential to inform patients of details in which their data is utilized. We identified five key non-functional properties from the requirement, which are availability, confidentiality, integrity, privacy, transparency. Interoperable HIE methods must authenticate participants so participants do not disguise or impersonate others. We identified authenticity as one of the key properties in this requirement. · Build upon the existing health IT infrastructure. The requirement requests stakeholders to improve interoperability based on their existing IT infrastructure. We identified the ease of integrating new data providers as one of the key properties. · Build a culture of electronic access and use. Interoperable HIE methods should be open to anyone, handling large and growing electronic health information to reduce the digital divide. We identified scalability as the key property. As a results, we identified eight key non-functional properties from the requirements. Using the key properties we · Authenticity. MEXchange authenticates new users through CA and manages them in the blockchain. Furthermore, MEXchange verifies that the ring signature consists only of the authorized participants to prevent unauthorized participants from engaging in exchange. · Availability. In MEXchange, metadata and permission are stored and managed in the blockchain, which assures data integrity and enables participants to exchange health information unless the blockchain is compromised. When a hospital's database is attacked, participants cannot exchange health information managed by the hospital. However, exchanging health information held by other hospitals is possible. · Confidentiality. With metadata and permission stored in the blockchain as encrypted form, only authorized participants can decrypt and access them. Also, hospitals provide requestors with health information upon confirming that the requestors were granted access. · Ease of integrating new data providers. MEXchange does not store health information in the blockchain but employs databases governed by the hospitals. Therefore, when a hospital becomes a participant, the hospital need not transfer health information elsewhere. · Integrity. MEXchange manages data through the blockchain, making it impossible for attackers to counterfeit data. Moreover, it stores the hash value of health information and metadata in the blockchain. Therefore, participants can confirm the integrity of data by comparing hash values. · Privacy. MEXchange enhances privacy by obscuring sender and receiver addresses using the ring signature and stealth address to prevent the inference problem. MEXchange also encrypts data stored in the blockchain and prevents sensitive information from leaking. Therefore, the data publicly visible in MEXchange is addr one−time , addr RV C , sig ring , addr ARC , SA, ephemKey, and reqID, except encrypted data. It is hard to infer senders and receivers with addr one−time , SA, and ephemKey, because they are transient data and are not linked to senders and receivers directly. Although sig ring and addr ARC contain information related to senders and receivers, it is hard to infer senders and receivers using the data. The sig ring includes the addresses of a sender and participants randomly selected; thus, it is difficult to de-anonymize senders compared to blockchain-based HIE without the ring signature. The address of the ARC refers to the access request storage where the patient monitors. Therefore, malicious participants could infer some participants using addr ARC . However, it is difficult to specify a receiver using addr ARC because some of the other patients also are included in the same access request storage. The remaining addr RV C and reqID are unrelated data to the senders and receivers. · Scalability. A disadvantage of the blockchain is being unable to handle a large volume of transactions since it continuously shares and verifies transactions among participants. Thus, MEXchange cannot handle large volumes of transactions quickly. Moreover, MEXchange has overhead due to the ring signature and stealth address, although it attempts to reduce the scan time by dividing participants into clusters. · Transparency. MEXchange allows patients to audit and trail sharing logs after exchanging health information with other participants. Therefore, the patients can obtain the logs from the blockchain and check the exchange history of their health information.

D. THREAT MODELING
This section describes the results of threat modeling. First, we derived the DFD of MEXchange as shown in Figure 14.
Based on the DFD, we identified threats to the MEXchange by referencing the Microsoft threat tool 2 . As a result, we identified 232 threats, with 33 for S and 54 for T, 27 for R, 87 for I, 2 for D, and 29 for E by category as explained in Table 2. Most of the spoofing threats involve the cases that malicious attackers gain unauthorized privileges on the business logic layer through participants' machines. The tampering threats are related to changing the databases managed by the patient, hospital, and certificate authority through SQL and malicious input injection. The repudiation threats involve denying the actions on the business logic layer and database managed by patients when storing metadata. In terms of information disclosure, there are threats of obtaining sensitive data from participants' devices or sniffing the device's traffic. For example, attackers . In terms of denial of service, there are threats of disrupting the participant registration and health information sharing service by attacking the CA and hospitals. Threats of elevation of privileges include obtaining privileges through attacks on participants' devices and unauthorized access to their database.  Table 3. Ancile, FHIRChain, and MedRec are the systems employing the blockchain to manage metadata and access permissions. IHE XDS is a document-based standard architecture designed for EHR sharing system [30]. In XDS, data providers register their health information in the document repository. Subsequently, the document repository submits the metadata of documents to the system called document registry.
· Authenticity. Ancile, FHIRChain, XDS, and MedRec authenticate new users through CA. After authentication, each system manages users' identity data in the blockchain. In XDS, a system called Patient Identity Source manages identity data. · Availability. Ancile, FHIRChain, and MedRec are similar to MEXchange in that they employ the blockchain and the hospitals' databases. However, Ancile utilizes proxy nodes to reduce the burden of key sharing. Thus, participants cannot exchange health information when proxy nodes are compromised. In XDS, metadata exchange is impossible if the document registry or repository is compromised. · Confidentiality. FHIRChain encrypts and stores data in the blockchain so only authorized participants can decrypt and access the data. Ancile also manages some data as an encrypted form but does not encrypt data such as database addresses and permission levels. XDS allows only authorized participants to access the document registry and repository. MedRec does not suggest a method or workflow for encrypting data stored in the blockchain. · Ease of integrating new data providers. Ancile, FHIR-Chain, and MedRec leave management of health information to the hospitals. A new hospital needs not to transfer health information elsewhere. However, in XDS, the hospitals register their health information in the document repository to share, which is additional work to the data providers. · Integrity. Ancile and MedRec manage metadata and permission in the blockchain and store the hash value of health information in the blockchain. Similarly, FHIR-Chain stores metadata in the blockchain to assure data integrity. However, it does not store the hash value of health information in the blockchain. In XDS, the document registry and repository are a single point where data can be falsified relatively easily by attackers. Thus, the participants cannot check the integrity of health information even data is manipulated. · Privacy. The inference problem can arise in Ancile, FHIRChain, and MedRec because senders and receivers are visible to any participants. Moreover, in MedRec, attackers can obtain personal information easily from the blockchain because it does not encrypt data. In XDS, personal information is less likely to leak because only permitted participants to access the system and obtain data. However, there is still a possibility of information leakage from entities that operate the XDS system. · Scalability. A disadvantage is that it is hard to handle a large volume of transactions. Thus, Ancile, FHIRChain, and MedRec cannot handle large transactions quickly. Compared to the blockchain-based HIE, XDS copes with the increasing volume of transactions through scale-up and scale-out flexibly because it is a centralized system managed by operators. · Transparency. Ancile, FHIRChain, XDS, and MedRec do not mention a method to record exchange history for patients to audit and trail.

B. CONTRIBUTIONS AND LIMITATIONS
Privacy and security concern is a major challenge for HIE and must be considered [3]. MEXchange enhances privacy by adopting the ring signature and stealth address to prevent the inference problems that arise from existing blockchainbased HIE. It encrypts data stored in the blockchain to increase confidentiality, which strengthens security. As we have suggested general smart contracts to utilize the ring signature and stealth address, MEXchange can be applied to any blockchain platform that supports smart contracts. With an overall workflow in health information sharing workflow and implemented prototype with Ethereum, we show that blockchain-based HIE with the ring signature and stealth address can be used in healthcare. Nonetheless, MEXchange has several limitations. MEXchange takes a long time to process access requests since ring signature verification requires many elliptic curve operations. As an alternative, the ring signature based on RSA, which shows better performance than ECC in encryption time, can be considered as future research. Furthermore, other blockchain and consensus algorithms such as Hyperledger Fabric, Corda, PoS(Proof-of-Stake), and DPoS(Delegated-Proof-of-Stake) which show better scalability than PoW can be considered. Second, we did not suggest the guidelines for the proper ring and cluster size. The larger the ring size is, the lower the possibility of inference. However, the time to generate and verify the ring signature takes more. Also, as the number of patients included in the cluster (cluster size) increases, inference becomes more difficult, but the number of transactions to be scanned increases. Therefore, future studies are needed to determine the appropriate ring and cluster size. Another limitation is that managing sensitive data such as private key, metadata, and ID HI can be burden for the patients. Such sensitive data should be managed safely because it is used for requesting and permitting health information exchange. Recently, some tools for blockchain key management have been developed for blockchain application users. Therefore, future research to manage the sensitive data can be considered when applying blockchain in the healthcare field. In addition, we did not consider the case that participants exchange wrong information. For example, when the patient delivers a wrong symmetric key to the requestor, a method for supporting the requestor to re-exchange the symmetric key is needed. In this case, we could consider 3way Diffie-Hellman key exchange as a solution. Therefore, we plan to proceed with further research for dealing with such a case. Finally, this research does not consider the different formats of health information. Therefore, future studies should consider the limitations mentioned above.

VII. CONCLUSION
This paper presented a blockchain-based HIE framework, MEXchange, that leverages the ring signature and stealth address to prevent the inference problem. We implemented the proposed framework as a prototype and evaluated it in the quantitative and qualitative aspects. Furthermore, we analyzed possible threats on MEXchange. Conclusively, MEXchange has disadvantages of increasing transaction latency and lower TPS compared to the existing blockchain-based HIE, however, it has advantages in availability, confidentiality, integrity, privacy, and transparency. In particular, MEXchange shows strength in the privacy aspect by preventing the inference problem. MEXchange has several limitations discussed in Section VI. As future works, we plan to increase the scalability, determine appropriate ring and cluster size, and consider different health information formats. To improve scalability, we will evaluate MEXchange on other blockchain platforms which reduce the time taken to generate and verify the ring signature. We will attempt to find out the proper ring size and cluster, which balances scalability and security. In addition, we will shorten the time to scan transactions, which reduces exchanging time. Also, additional measures are needed to defend against threats arise in the local function VOLUME 4, 2016 and database. Lastly, we will make it possible to exchange health information between hospitals that use different health information formats. Complementing the limitations, we expect that MEXchange lowers barriers to the actual application of blockchain-based HIE systems by mitigating concerns over privacy and security.