DynamiChain: Development of Medical Blockchain Ecosystem Based on Dynamic Consent System

: Although blockchain is acknowledged as one of the most important technologies to lead the fourth industrial revolution, major technical challenges regarding security breach and privacy issues remain. This issue is particularly sensitive in applied medical ﬁelds where personal health information is handled within the network. In addition, contemporary blockchain-converged solutions do not consider restricted medical data regulations that are still obstacles in many countries worldwide. This implies a crucial need for a system or solution that is suitable for the healthcare sector. Therefore, this article proposes the development of a dynamic consent medical blockchain system called DynamiChain, based on a ruleset management algorithm for handling health examination data. Moreover, medical blockchain-related studies were systematically reviewed to prove the novelty of DynamiChain. The proposed system was implemented in a scenario where the exercise management healthcare company provided health management services based on data obtained from the data provider’s hospital. The proposed research is envisioned to provide a widely compatible blockchain medical system that could be applied in future healthcare ﬁelds.


Introduction
As part of the fourth industrial revolution in recent years, the advancement in blockchain technology has brought back the original theorem regarding smart contracts. Such algorithms based on computer protocols were designed to automatically facilitate, verify, and enforce the negotiation and implementation of digital contracts within an authority distributed architecture [1][2][3]. Smart contracts are being applied to a wide range of fields, mainly from the digital economy to healthcare, and the Internet of Things (IoT) [4]. To date, there is still a trend to use mainstream blockchain platforms, such as Bitcoin and Ethereum, when developing such platforms [5,6].
However, smart contract-related core technology is still in its infancy, and major technical challenges regarding security breach and privacy issues still exist. For example, blockchain cannot guarantee transactional privacy, since the values of all transactions and balances for each public key are publicly visible [7,8]. Moreover, a user's Bitcoin transactions can be linked to reveal user's information [9]. Similarly, each client can be uniquely identified by a set of nodes it connects [10]. "DAO Attack" that occurred in June 2016 [11][12][13] might be one of the most well-known blockchain targeted attacks. It was a severe incident that resulted in a loss amounting to more than $50 million Ether (approximately worth more than 8.5 billion dollars at that time) being transferred to an unauthorized account. This type of security breach is particularly sensitive in the medical industry, where personal health or medical information is being transferred within the network. In addition, contemporary blockchain-converged solutions do not consider restricted medical data regulations that are still obstacles in many countries worldwide.
In addition, current medical systems lack evidence-based data sharing policy, making it difficult for data providers to control their data based on their desired settings or policies. Some of the core values that blockchain technology aims to achieve, which are distributed authority, and consensus-based security, could play a vital role in providing these data providers with the rights they have over their own health data. This implies a crucial need for a system or solution that is suitable for the healthcare sector.
This paper, therefore, proposes the development of a medical blockchain ecosystem based on a dynamic consent system. The proposed solution not only solves security issues by using blockchain technology, but also tackles the problem of privacy piracy by adopting a dynamic consent algorithm original to this research. Our developed system was applied in a practical healthcare business application scenario focusing on actual physical examination of big data being used for health services. Moreover, a medical blockchain-related studies were reviewed to prove the novelty of the system in terms of dynamic applicability and expandability. The proposed solution is envisioned to provide a successful example for future blockchain applied medical systems to be extended to other disease areas or medical databases.
The rest of this paper is organized as follows. Section 2 gives a brief review of the state-of-the-art approaches for blockchain technology. Section 3 provides comprehensive details of the whole DynamiChain. Section 4 describes the specific implementation of DynamiChain. Section 5 highlights the novelty of DynamiChain, and finally, the Section 6 concludes the discussion with the extension of DynamiChain in the future.

Related Concept
The algorithm of proof of work (PoW)-based cryptocurrencies, such as Bitcoin, is focused on solving the computationally intensive puzzle to validate transactions and create new blocks. That is, the best computational performance mining node is prioritized when it is selected as the next creator of the new block. The concept was invented by Cynthia Dwork and Moni Naor, as presented in a 1993 journal article [14]. The term "proof of work" was first coined and formalized in a 1999 paper by Markus Jakobsson and Ari Juels [15], and today it is the most widely applied algorithm in all blockchains. However, the PoW method has the disadvantage of wasting resources by consuming a huge amount of electricity and is heavily influenced by computing resources, such as graphics cards and ASIC chips, resulting in the formation of large mining pools that are approaching centralization. A new consensus mechanism that compensates for the PoW limitation is Proof of Stake (PoS), which is based on on-chain currency pricing. PoS is the concept of randomly selecting who will create the next block among the participants of the blockchain network, and several studies have begun to develop this concept further. Song et al. proposed PoS based on competition (CPoS) based on forging committee mechanism to solve the problem of rich people getting richer easily in traditional PoS mechanism and improve the productivity and liquidity of the system [16]. Zhao et al. applied Delegated PoS (DpoS), which is more effective, more decentralized, and more flexible consensus mechanism, in the blockchain network and reduced the number of recording nodes in the block and increased the recording efficiency of the block [17].
The smart contracts have trigger conditions and the corresponding response actions on the terms of the contract. These terms are preset using trigger condition statements, such as "If-Then" statements. Smart contracts are agreed upon and signed by all parties (consensus) and submitted in transactions to the blockchain network. Such transactions are broadcast to the blockchain network, verified by mining nodes. In a blockchain network, synergy occurs when attack vectors of various IoT devices are analyzed and categorized, and combined with the classify results based on hardware, network, and software [18].
Miners' verification activities are motivated by the system's incentive policies (usually cryptocurrencies) and will contribute their computing resources to verify as much transaction as their capacity allows. When a transaction is finally validated, it is packaged into a new block. The new block is chained as one of the infinite series of blockchains once the entire network reaches a consensus. The creation and execution of a smart contract are fundamentally enforced among anonymous, decentralized individual nodes. These smart contracts are verified on the blockchain, making them resistant to malignant tampering that is not based on participants' pre-agreed consent [19,20].

Related Research
Despite heavy regulations and bureaucratic inefficiency in the medical field, some prior studies have attempted to innovate the converging blockchain and medicine. Azaria et al. proposed MedRec [21], a novel, decentralized record management system to handle electronic medical records (EMR) using blockchain technology. Their proposed system can be summarized as a system that provides data providers with a comprehensive, immutable log and easy access to their medical information across providers and treatment sites. MedRec mainly ensures authentication, confidentiality, accountability, and data sharing crucial considerations when handling sensitive information. Their system also provides mining rewards in return for sustaining and securing the PoW-based network. The system provides a sustainable system powered by the big data economy, which fundamentally rewards data providers and providers in their choice to release metadata.
Similarly, Fan et al. proposed a blockchain-based information management system, MedBlock, to handle information from data providers [22]. In their proposed scheme, the distributed ledger of MedBlock allows efficient EMRs access and retrieval. MedBlock's consensus mechanism achieves a consensus of EMRs without high energy consumption and network congestion. In addition, MedBlock exhibits a high level of information security by combining customized access control protocols and symmetric cryptography, providing a secure platform for sharing of sensitive medical information.
In addition, although blockchain is not applied to the medical field, there are many studies using blockchain. Jiang et al. proposed a new blockchain-based authentication protocol for WLAN mesh security access, to reduce the deployment costs and resolve the issues of requiring key delivery and central server during authentication [23]. Borja et al. defined a theoretical framework for trust in IoT scenarios, and practically implemented the solution based on the blockchain technology as it meets both, the mathematical formalization and the usual requirements for trust provision systems [24]. Singh et al. detailed the discussion of several key factors for the convergence of Blockchain and AI technologies that will help form a sustainable smart society by blockchain security enhancement solutions, summarizing the key points that can be used for developing various blockchain-AI based intelligent transportation systems [25]. Yan et al. puts forward a blockchain framework based on mobile edge computing, in which the blockchain mining tasks can be offloaded to nearby the edge computing service providers, and the encrypted hashes of blocks can be cached in the edge computing service providers. Moreover, they model the process of offloading and caching to ensure that both edge nodes and edge computing service providers obtain the maximum profit [26]. Nguyen et al. presents a new privacy-preserving Secure Ant Colony optimization with multi-kernel support vector machine with elliptical curve cryptosystem for secure and reliable IoT data sharing based on blockchain to ensure protection and integrity of data [27]. Wang et al. analyses the security requirements of electronic records. Then, based on the characteristics of blockchain decentralization with coding theory, a distributed secure provenance guarantees technology of electronic records is constructed ensuring the authenticity, integrity, confidentiality, and reliability of the provenance information [28]. Cheng  mobile client privacy protection system that utilizes the trusted execution environment to provide a new method for privacy protection based on blockchain. They design the authentication mechanism and privacy protection strategy based on Intel software guard extensions to achieve hardware-enhanced data protection, and the blockchain network is to store the hash memory table, which uniquely identifies the data from SGX [29].
Moreover, there are many studies that can safely and effectively manage medical data. Ali et al. proposes the designed to resolve challenges in regression testing in componentbased healthcare cloud-enable systems while supporting continuous dynamic change decision and implementation activities in modern software development organizations [30]. Singh et al. works on some public cloud and private cloud authorities, as well as related security concerns. Additionally, it encompasses the requirements for better security management and suggests 3-tier security architecture [31]. Naresh et al. provides a review of IoT in the healthcare domain by first describing the enabling technologies for delivering smart healthcare. In addition, a fog-based architecture consisting of three layers for IoT-based healthcare applications is proposed [32]. Parvathavarthini et al. modifies crow search algorithm by introducing the genetic operators like cloning and mutation operators. In addition to that, the study creates an archive of memory to store the best solutions of the iterations, and these values are used for updating the position when the acquired solutions are not feasible [33].

Overall System Architecture
The overall system architecture of DynamiChain is shown in Figure 1. As mentioned previously, the proposed medical blockchain network was specialized to handle health examination big data, which consists of Inbody [34] tested, blood test, and functional test datasets. The specific data specifications are explained in Section 4.1.
chain decentralization with coding theory, a distributed secure provenance guarantees technology of electronic records is constructed ensuring the authenticity, integrity, confidentiality, and reliability of the provenance information [28]. Cheng et al. presents a highly effective and secure lightweight mobile client privacy protection system that utilizes the trusted execution environment to provide a new method for privacy protection based on blockchain. They design the authentication mechanism and privacy protection strategy based on Intel software guard extensions to achieve hardware-enhanced data protection, and the blockchain network is to store the hash memory table, which uniquely identifies the data from SGX [29].
Moreover, there are many studies that can safely and effectively manage medical data. Ali et al. proposes the designed to resolve challenges in regression testing in component-based healthcare cloud-enable systems while supporting continuous dynamic change decision and implementation activities in modern software development organizations [30]. Singh et al. works on some public cloud and private cloud authorities, as well as related security concerns. Additionally, it encompasses the requirements for better security management and suggests 3-tier security architecture [31]. Naresh et al. provides a review of IoT in the healthcare domain by first describing the enabling technologies for delivering smart healthcare. In addition, a fog-based architecture consisting of three layers for IoT-based healthcare applications is proposed [32]. Parvathavarthini et al. modifies crow search algorithm by introducing the genetic operators like cloning and mutation operators. In addition to that, the study creates an archive of memory to store the best solutions of the iterations, and these values are used for updating the position when the acquired solutions are not feasible [33].

Overall System Architecture
The overall system architecture of DynamiChain is shown in Figure 1. As mentioned previously, the proposed medical blockchain network was specialized to handle health examination big data, which consists of Inbody [34] tested, blood test, and functional test datasets. The specific data specifications are explained in Section 4.1. Participants include various parties, such as data providers (e.g., patents, holders of health examination data) and data utilizers (e.g., medical professionals, medical institutions, insurance companies, research institutions, and health service companies). Data providers, which are the main party of this network, have established a dynamic consent Participants include various parties, such as data providers (e.g., patents, holders of health examination data) and data utilizers (e.g., medical professionals, medical institutions, insurance companies, research institutions, and health service companies). Data providers, which are the main party of this network, have established a dynamic consent rule in three main parts: Consent level, approval duration, and approval target. Data utilizers can only participate under dynamic conditions set by the data providers in charge of their own medical data. Data utilizers use this hyperledger-based network under a dynamically set consent. The specifications for the three main dynamic rules are explained in the Section 3.2.

Specific System Functions
The functions that comprise the overall system mentioned in the previous section are explained in this Section. The list of the function contents is shown in Table 1. Through the data provider's app, data providers may not only view their own health data, but also change dynamic consent rule settings. They have full access to the ledger, which includes the history of which data utilizer viewed or used their data.
By using the data utilizer's app, any data utilizers may access data providers' health examination data based on set rules. They may also act as a "mining node" (mining, in terms of blockchain), to be rewarded for checking if the transmitted data are real. Since hospitals are the main provider for the hospital examination data provider data, numerous data management functions can be enforced with this app. Even if the requested data meet the settings set by the data provider, the hospital finally confirms whether or not the transaction should be made. This function may be disabled in countries that do not have restricted medical data policies. Explanation of restricted medical data policies will be further explained in Section 3.4.
The hash function of the blockchain system is created and matched to each health data. In addition, this function is automatically synced with real-time changing consent settings by each data provider. Most importantly, all transaction history is stored for data integrity and security in each blockchain. Finally, the blockchain admin web functions enable the super administrator to monitor the status of the entire channel, participating peer nodes, and participating users (i.e., data provider and data utilizer) within the blockchain network.

Dynamic Consent Algorithm
Medical data is an intangible asset that requires time and effort from a medical institution or individual. It is intertwined with users, service providers, data carriers, etc., requiring a consent system algorithm that all participants can intuitively understand and agree on. To meet these needs, this paper applied the dynamic consent concept on a new customized consent system, called "dynamic consent algorithm". The system is tailored to the individual user's taste, minimizing the user's resistance to data disclosure. Furthermore, by implementing this dynamic consent algorithm in the chaincode mentioned in Section 4, this paper developed a consent system algorithm that is transparent and integrated to all participants in the consensus operation of the blockchain. Our proposed dynamic consent algorithm includes data type, approval duration, and objectives ( Figure 2).

Dynamic Consent Algorithm
Medical data is an intangible asset that requires time and effort from a medical institution or individual. It is intertwined with users, service providers, data carriers, etc., requiring a consent system algorithm that all participants can intuitively understand and agree on. To meet these needs, this paper applied the dynamic consent concept on a new customized consent system, called "dynamic consent algorithm". The system is tailored to the individual user's taste, minimizing the user's resistance to data disclosure. Furthermore, by implementing this dynamic consent algorithm in the chaincode mentioned in Section 4, this paper developed a consent system algorithm that is transparent and integrated to all participants in the consensus operation of the blockchain. Our proposed dynamic consent algorithm includes data type, approval duration, and objectives ( Figure 2). The term data type refers to data providers setting the type of data they wish to provide to other data utilizers. Data providers can choose from three data types: Data derived basically, out-of-hospital-level tests, and data derived from hospital-level tests. For example, basic data refer to social demographic data, such as age, sex, and address. Out-ofhospital tests refer to basic health tests that data providers can easily achieve through home healthcare devices, such as thermometers, InBody tests, or other healthcare-related devices. On the other hand, data obtained from hospital-level tests are more in-depth because data providers can only achieve such data when they visit the hospital. The specific contents of these three classifications are shown in Table 2.  The term data type refers to data providers setting the type of data they wish to provide to other data utilizers. Data providers can choose from three data types: Data derived basically, out-of-hospital-level tests, and data derived from hospital-level tests. For example, basic data refer to social demographic data, such as age, sex, and address. Out-ofhospital tests refer to basic health tests that data providers can easily achieve through home healthcare devices, such as thermometers, InBody tests, or other healthcare-related devices. On the other hand, data obtained from hospital-level tests are more in-depth because data providers can only achieve such data when they visit the hospital. The specific contents of these three classifications are shown in Table 2. Approval duration refers to data providers setting the exposure duration of their personal medical data to other data utilizers. By default, data providers can simply select 6 months, 12 months, or unlimited duration. This can always be changed by accessing the system settings. The third objective refers to data providers selecting which data utilizer they desire to provide their personal medical data according to the usage objective. With this function, data providers can, by default, select any group based on these four classifications: Clinical, research, healthcare service, and other services. Any data utilizers (mainly hospitals) that registered into our proposed system with the objective of using physical examination data for clinical matters are classified as "Clinical." Similarly, all groups (mainly universities or research institutions) whose data usage objective is for research are classified as "Research." Most health insurance companies are classified as "Healthcare services," and other data utilizers with other needs are classified as "Other services."

Restricted Medical Data Policy Applied Work Flow Specifications
Some countries worldwide, including South Korea, still prohibit healthcare data to be stored outside certified medical institutions. Considering this, the proposed system only saves hash values of the health examination data and stores actual medical data separately in another database. Medical data's multiple hash values are stored in the blockchain ledger so that data utilizers could read the data providers' data based on set rules. Encoding-decoding access key to the actual medical data is, by default, managed by the data provider, unless the data provider delegates his or her authority to medical institutions where the actual database is stored. Using this mechanism, we balanced the data co-ownership ecosystem while preserving data integrity in a practical situation. This service process is shown in Figure 3. The hospital generates health an examination data of a data provider than the hash management system encrypts the data with the data provider's public key and stores them with the hash value of the data. The data provider then confirms the data itself and dynamic consent rule in real-time and modifies the setting of the rules if necessary. The data utilizer requests for the data of the data provider, and the hospital confirms the request. The hospital allows access to actual data transmission after the endorsement process. Finally, data utilizer read the requested data through hash value comparison.  Hospital type data are created when data providers visit the hospital for a health examination. For each data, our proposed system stores encoded data, and accordingly, it has the data provider public key. Data providers have access to their own physical data and can set or change their dynamic consent rule in real-time. When other data utilizers (e.g., companies and research institutions) request for the allowed data providers' medical data, the data source hospital confirms this request before transmitting the actual medical data to the requested data utilizer. Thereafter, the data utilizers could read the requested data. This is the key process that not only overcomes the issue of restricted health data sharing policies for some countries, but also guarantees data integrity. Note that out-hospital-data types are free from this scenario.

DynamiChain Network Based on Hyperledger Fabric
Because of the sensitivity of healthcare data, DynamiChain was implemented using Hyperledger Fabric Blockchain technology (version 2.2.0), one of the permissioned and private blockchains that enhanced privacy [35]. It was established as a network that allows data utilizers to operate peer nodes. A hyperledger chaincode-based smart contract was implemented to store data in the blockchain and to distribute it to peer nodes. The original medical data from the data provider are implemented in the off-chain of the blockchain system, and the hash values of the medical data are stored on-chain, where dynamic con- Hospital type data are created when data providers visit the hospital for a health examination. For each data, our proposed system stores encoded data, and accordingly, it has the data provider public key. Data providers have access to their own physical data and can set or change their dynamic consent rule in real-time. When other data utilizers (e.g., companies and research institutions) request for the allowed data providers' medical data, the data source hospital confirms this request before transmitting the actual medical data to the requested data utilizer. Thereafter, the data utilizers could read the requested data. This is the key process that not only overcomes the issue of restricted health data sharing policies for some countries, but also guarantees data integrity. Note that out-hospital-data types are free from this scenario.

DynamiChain Network Based on Hyperledger Fabric
Because of the sensitivity of healthcare data, DynamiChain was implemented using Hyperledger Fabric Blockchain technology (version 2.2.0), one of the permissioned and private blockchains that enhanced privacy [35]. It was established as a network that allows data utilizers to operate peer nodes. A hyperledger chaincode-based smart contract was implemented to store data in the blockchain and to distribute it to peer nodes. The original medical data from the data provider are implemented in the off-chain of the blockchain system, and the hash values of the medical data are stored on-chain, where dynamic consent system rules are applied to control the data provider's medical data.
Three organizations, such as data providers, data utilizers, and hospital, form a consortium in DynamiChain ( Figure 4). Mainly, data providers can set their dynamic consent rules, and we updated the chaincode according to the rules. Hospitals can store medical data transmission records and manage overall health examination data transmission. Data utilizers can compare health examination data hashes and read health examination data, respectively. The consortium is joined by all three organizations through one channel (Channel1). Additional participation on the consortium can be established through the configuration block stored in the ordering service, including peer, channel, client, network policy, and channel policy, after establishing the ordering service node, Orderer1, under consultation between organizations. Channel1 is created through Orderer1, and Channel1 provides the ability to share data only between organizations that share interests among consortiums. Organization1-3 will install their own peer in their data center and then participate in Channel1. Every peer has the role of communing/reader/anchor peer, and only the Peer3 has the role of endorsing peer additionally. The peers participating in Channel1 can store Distributed Ledger1 used on Channel1 in their local repository and share data. Chaincode1 has a smart contract function for the purpose of the Channel1 participants and is installed on every peer. Every participant on Channel1 must use our newly developed Dapp to participate in the network and send a transaction to the peers where the Chaincode1 is installed. Dapp commonly consists of a UI front end, REST API [36] backend, and Fabric Software Development Kit [37] (SDK, based on node.js).
Appl. Sci. 2021, 11, x FOR PEER REVIEW 9 of 20 utilizers can compare health examination data hashes and read health examination data, respectively. The consortium is joined by all three organizations through one channel (Channel1). Additional participation on the consortium can be established through the configuration block stored in the ordering service, including peer, channel, client, network policy, and channel policy, after establishing the ordering service node, Orderer1, under consultation between organizations. Channel1 is created through Orderer1, and Channel1 provides the ability to share data only between organizations that share interests among consortiums. Organization1-3 will install their own peer in their data center and then participate in Channel1. Every peer has the role of communing/reader/anchor peer, and only the Peer3 has the role of endorsing peer additionally. The peers participating in Channel1 can store Distributed Ledger1 used on Channel1 in their local repository and share data. Chaincode1 has a smart contract function for the purpose of the Channel1 participants and is installed on every peer. Every participant on Channel1 must use our newly developed Dapp to participate in the network and send a transaction to the peers where the Chaincode1 is installed. Dapp commonly consists of a UI front end, REST API [36] backend, and Fabric Software Development Kit [37] (SDK, based on node.js).

Dynamic Consent System
Dynamic consent algorithm is implemented in the Chaincode1, and blocks are generated throughout the following process ( Figure 5). In this process, the participant called Data Provider1 in Org1 tries to send their data to the hospital in Org3 according to the dynamic consent system through the Dapp1. First, Data Provider1 requests transaction generation to send the data to the hospital via Dapp1 (Figure 5a). After receiving the trans-

Dynamic Consent System
Dynamic consent algorithm is implemented in the Chaincode1, and blocks are generated throughout the following process ( Figure 5). In this process, the participant called Data Provider1 in Org1 tries to send their data to the hospital in Org3 according to the dynamic consent system through the Dapp1. First, Data Provider1 requests transaction generation to send the data to the hospital via Dapp1 (Figure 5a). After receiving the transaction generation request, Dapp1 generates a transaction that contains the message of sending data and sends the transaction to the endorsing peer, Peer3. Peer3 can be connected to Dapp1 after passing the certification process using the certificate of Data Provider1. After connection, Dapp1 calls up the update function of the chaincode installed in Peer3 and requests the chaincode execution (Figure 5b). Upon receipt of the transaction from Dapp1, Peer3 simulates the chaincode by referring to the World State DB and checks the results of read/write set to determine whether it is endorsed or not (Figure 5c). If the transaction execution result is valid and the endorsement of Peer3 is passed, Peer3 sends the results and the digital certificate of Peer3 to Dapp1 (Figure 5d). Receiving the simulation results from Peer3, Dapp1 checks to see if the value of the read/write set is the same as its expected value and checks whether the digital certificate of Peer3 has been received. After verification, Dapp1 broadcasts the transaction containing the digital certificate of Peer3 and the results of read/write set to the Orderer1 node to create the block (Figure 5e). The Orderer1 identifies the time stamp fields, which is required to order the transactions, and then orders the transactions to be included in the block to create the latest blocks (Figure 5f). After that, Orderer1 delivers the created blocks to all the peers on the network (Figure 5g). Every peer who receives the latest block performs verification by running a Validation System ChainCode (VSCC) system chain code to verify the results and certificates of all transactions contained in the block. If the validation process is passed, all the peers update the distributed ledger stored in their local repository (Figure 5h). Peers complete the distributed ledger update process by sending the results of the updated distributed ledger to Dapp1 (Figure 5i). the results of read/write set to determine whether it is endorsed or not (Figure 5c). If the transaction execution result is valid and the endorsement of Peer3 is passed, Peer3 sends the results and the digital certificate of Peer3 to Dapp1 (Figure 5d). Receiving the simulation results from Peer3, Dapp1 checks to see if the value of the read/write set is the same as its expected value and checks whether the digital certificate of Peer3 has been received. After verification, Dapp1 broadcasts the transaction containing the digital certificate of Peer3 and the results of read/write set to the Orderer1 node to create the block (Figure 5e). The Orderer1 identifies the time stamp fields, which is required to order the transactions, and then orders the transactions to be included in the block to create the latest blocks (Figure 5f). After that, Orderer1 delivers the created blocks to all the peers on the network (Figure 5g). Every peer who receives the latest block performs verification by running a Validation System ChainCode (VSCC) system chain code to verify the results and certificates of all transactions contained in the block. If the validation process is passed, all the peers update the distributed ledger stored in their local repository (Figure 5h). Peers complete the distributed ledger update process by sending the results of the updated distributed ledger to Dapp1 (Figure 5i).

Security Management System
Blockchain security comprises mainly confidentiality, integrity, availability (CIA) [38]. DynamiChain also meets the CIA by complementing the existing public blockchain model.
Since information is open and cannot be restricted from participating in the traditional public blockchain, it is very difficult to meet consistency. DynamiChain uses private

Security Management System
Blockchain security comprises mainly confidentiality, integrity, availability (CIA) [38]. DynamiChain also meets the CIA by complementing the existing public blockchain model.
Since information is open and cannot be restricted from participating in the traditional public blockchain, it is very difficult to meet consistency. DynamiChain uses private blockchain's channel to meet confidentiality by only allowing pre-selected participants to join the network. Moreover, not only are digital certificates safely managed by applying Fabric-CA, but also sensitive data are encrypted by implementing Private Data Collection (PDC).
In the existing public blockchain, Public Key Infrastructure (PKI) based on hash algorithms is used to prevent the manipulation of the block, and each block stores the information of not only the current block, but also the previous block. DynamiChain also take advantage of the existing public blockchain's attribute. In addition, DynamiChain increases its integrity by requiring all the peers to periodically verify the current block state before adding a new block, therefore, reducing the possibility of peer hacking.
In the traditional blockchain, as well as DynamiChain, data are accessible from the rest of the nodes even if one node is not working. All nodes are kept and decentralized with the same contents, preventing a single point of failure to gain availability. Furthermore, from the generation of transactions process to the consensus process, it can be processed individually in stages, which improves the performance by allowing parallel processing to perform more than one task at the same time. A user management system and a key management system are the two main components of the security management system. The user management system ( Figure 6) manages the actual users for creating, blocking, and deleting (Figure 6a) data providers and data utilizers. Data providers can create additional accounts under a dynamic consent framework by requesting the super administrator. Data utilizers can also create additional accounts by requesting the super administrator (Figure 6b) by specifying the purpose of data usage information (e.g., clinical, research, and healthcare). Figure 6c shows the DynamiChain interface of the user management system implementation screen showing the management list according to the user type. The functions for managing the permissions of data providers and data utilizers were implemented in the super administrator account. A super administrator can create, block, and disable accounts of the data provider and user. If a user is created, a key in the blockchain is also generated. If a user is blocked, it is impossible to login to the system. The data provider sets the access permissions of the data according to the dynamic consent system. The data utilizer manages and utilizes the data according to the access permission set by the data provider.
The key management system requires a key to sign the blockchain for each user. The key to the data provider is generated when he or she joins the web service (Figure 7a). The ECDSA algorithm was used to generate private and public keys. The generated keys are stored in a key-store-only wallet within the server (Figure 7b). The keys of the super administrator and the user are distinguished. For security purposes, each user maintains the key in a separate wallet.
In Table 3, medical blockchain-related studies (2016 to 2020) were reviewed to prove the novelty of the system in terms of dynamic applicability and expandability.
type. The functions for managing the permissions of data providers and data utilizers were implemented in the super administrator account. A super administrator can create, block, and disable accounts of the data provider and user. If a user is created, a key in the blockchain is also generated. If a user is blocked, it is impossible to login to the system. The data provider sets the access permissions of the data according to the dynamic consent system. The data utilizer manages and utilizes the data according to the access permission set by the data provider. The key management system requires a key to sign the blockchain for each user. The key to the data provider is generated when he or she joins the web service (Figure 7a). The ECDSA algorithm was used to generate private and public keys. The generated keys are stored in a key-store-only wallet within the server (Figure 7b). The keys of the super administrator and the user are distinguished. For security purposes, each user maintains the key in a separate wallet. In Table 3, medical blockchain-related studies (2016 to 2020) were reviewed to prove the novelty of the system in terms of dynamic applicability and expandability.

Discussion
The case scenario showed that companies can provide, for example, health AI convergence technology-based home training services [68], dietary consumption recommendation services [69], or health beauty services (e.g., cosmetics recommendation [70]) based on individual data provider specialized health data. Insurance companies can also use these data based on the limits set by each data provider. Our proposed system is envisioned to allow several health technology converged services to be launched, contributing to the vitalization of the next-generation healthcare industry converged with proper blockchain technology.
In addition, data integrity and data security, which are a few of the main important blockchain functions mentioned in this paper, provide a solid ground for future personal health records (PHRs) to be rapidly applied in medical systems. Most importantly, the dynamic consent, which can be set by the data owners (data providers), provides the proposed system high reliability and credibility so that data owners do not have to worry about data piracy or data abuse.
As mentioned above, including South Korea, there are many countries [71][72][73] that have strong regulations against medical data being stored or being transmitted outside certified medical boundaries without strict authorization. Another unique characteristic of our proposed system is that we considered this by adopting the hash-data sync system. By doing so, the actual data did not have to be transmitted unless there was an actual need for the raw data to be transmitted. Otherwise, there would be a regulation huddle for every blockchain transaction.
Several medical blockchain-related studies were reviewed to prove the novelty of DynamiChain in terms of dynamic applicability and expandability (Table 3). Most studies were conducted based on EMR data, not using the other forms of out-of-hospital healthcare data, such as data acquired from mobile healthcare devices ("Target Data" column). Moreover, most of the target patients they dealt with were mainly patients, hospitals, and researchers ("Target Participant" column). That is, they did not consider the additional participation of third parties, such as healthcare service providers, healthy persons (not patients). In addition, data open consent was not dynamically considered in previous studies, which allowed data providers little control over their own data ("Consensus Mechanism" column). Most studies focused only on system implementation and performance evaluation and did not develop DApps that could be used directly by the data providers, resulting in a lack of use cases in the actual scenarios ("System Architecture" column).
They also lacked specific explanation and analysis of data characteristics compared to the proposed research ("Not Addressed" column).

Conclusions
This paper proposes DynamiChain, the medical blockchain based on a dynamic consent system and security management system for handling physical examination data. DynamiChain supports modular designs based on the dynamic consent algorithm so that participants can select functions, such as authentication, consensus algorithms, and encryption in the form they want to operate the blockchain. This modularized design provides flexibility because it enables the development of various network models as more organizations to participate in the future. The overall specifications are explained in Section 3, and the actual implementation scenario is presented in Section 4, handling the case of a health service company providing business using our system.
The limitation of this research is that the implementation scenario was conducted in a limited area. More practical implementation should be enforced in actual situations. This research is currently being conducted under a three-year Ministry of Health and Welfare governmental funding project worth a total of 400,000 CHF funds. It has started in 2019, making 2020 the second year, and 2021 the final year. During the first two years, this research project's goal was full development. The final year, which is next year, is the scheduled performance evaluation of the fully developed system.
For future research, actual data should be cumulated and analyzed to evaluate the performance of the proposed system. The proposed research is envisioned to provide a widely compatible blockchain medical system that could be applied in future healthcare fields.

Conflicts of Interest:
The authors declare no conflict of interest.