DeepBlockShield: Blockchain Agent-Based Secured Clinical Data Management Model from the Deep Web Environment

With the growth of artificial intelligence in healthcare and biomedical research, many researchers are interested in large amounts of data in hospitals and medical research centers. Then the need for remote medicine services and clinical data utilization are expanding. However, since the misuse and abuse of clinical data causes serious problems, the scope of its use is bound to have a limited range physically and logically. Then a security-enhanced data distribution system for medical deep web environments. Therefore, in this paper, we propose a blockchain-based clinical data management model named DeepBlockshield to prevent information leakage between the deep web and the surface web. Blockchain supports data integrity and user validation to support data sharing in closed networks. Meanwhile, the agent performs integrity verification between the blockchain and the deep web and strengthens the security between the surface web and the deep web. DeepBlockShield verifies the user’s validity through the records of the deep web and blockchain. Furthermore, we wrap the results analyzed by the valid request into a web interface and provide information to the requester asynchronously. In the experiment, the block generation cycle and size on the delay time was analyzed for verifying the stability of the blockchain network. As a result, it showed that the proposed approach guarantees the integrity and availability of clinical data in the deep web environment.


Introduction
In spite of the fact that the development of artificial intelligence (AI) in healthcare and biomedical research is advancing rapidly, there are many challenges and limitations (i.e., privacy, diagnosis ethics) in the real-world use of AI algorithms in clinical practice. Advanced bioinformatics for diagnosis, prognosis, and treatment can be realized based on a variety of data, then a system for secured clinical data distribution should be ensured. Meanwhile, information produced in various industries is being loaded into a closed network, and while actively participating in the production process as well as big data and IoT, the web becomes more diverse and subdivided [1][2][3]. Figure 1 shows the hierarchy of web environments which consist of surface, deep and dark web. Surface Web generally means World Wide Web (WWW), namely many social network services (i.e., Facebook, Twitter) and search engines (i.e., Google, Yahoo, and Bing) belong to it. The deep web, separated from the surface web, has accumulated over 90% of data in various fields such as language, medicine, and government [4][5][6]. It takes the role of a specialized data warehouse in a closed network environment. Hence, it is not only inaccessible to unauthorized people; it also does not allow indexing in regular search engines. Typically, clinical data resides on the deep web. In fact, it exists on the deep web and is provided in a limited format to prevent the leakage of sensitive personal information. However, the use of this data is increasing for the development of diagnostic technology and services [7]. In addition, the scope of use for medical disputes and criminal investigations has expanded even further. Its use was generally not permitted due to the potential for certain problems, including unauthorized use, leakage, abuse and misuse.
Currently, information-sharing programs in the field of medical research focus solely on collection and use. Most of the data generated by medical institutions is stored in databases. It is basically encrypted using digital signatures or DRM (digital rights management). However, in this storage method, if someone obtains the authority of an administrator, clinical data can be edited and arbitrarily modified. It can also be forged by an authorized person while being transferred or stored in the database. Moreover, if it is transmitted in text format on the network, it can be leaked by sniffing attack [8]. Recently, research on strengthening security based on blockchain is underway. In general, in order to safely utilize this technology, the stability of the technology is secured by establishing a network through a private blockchain and consensus algorithm in which only authorized users participate [9][10][11][12]. In the case of shared ledgers, the history is recorded, and the usage flow is verified [13,14].
With the innovation of artificial intelligence technology, the use of clinical data in a deep web environment has become important. However, due to personal information leakage and abuse, its use still remains stagnant. In this paper, we implement a blockchain-based agent that prevents information leakage and provides a secure clinical data management model. The proposed DeepBlockShield implements a horizontal security system that prevents data leakage in the surface web environment and a vertical management system between the deep web and the surface web. The agent performs authentication to determine access rights to clinical data, and users can be divided to researchers and administrators according to their rights. Data analysis requests are passed through Typically, clinical data resides on the deep web. In fact, it exists on the deep web and is provided in a limited format to prevent the leakage of sensitive personal information. However, the use of this data is increasing for the development of diagnostic technology and services [7]. In addition, the scope of use for medical disputes and criminal investigations has expanded even further. Its use was generally not permitted due to the potential for certain problems, including unauthorized use, leakage, abuse and misuse.
Currently, information-sharing programs in the field of medical research focus solely on collection and use. Most of the data generated by medical institutions is stored in databases. It is basically encrypted using digital signatures or DRM (digital rights management). However, in this storage method, if someone obtains the authority of an administrator, clinical data can be edited and arbitrarily modified. It can also be forged by an authorized person while being transferred or stored in the database. Moreover, if it is transmitted in text format on the network, it can be leaked by sniffing attack [8]. Recently, research on strengthening security based on blockchain is underway. In general, in order to safely utilize this technology, the stability of the technology is secured by establishing a network through a private blockchain and consensus algorithm in which only authorized users participate [9][10][11][12]. In the case of shared ledgers, the history is recorded, and the usage flow is verified [13,14].
With the innovation of artificial intelligence technology, the use of clinical data in a deep web environment has become important. However, due to personal information leakage and abuse, its use still remains stagnant. In this paper, we implement a blockchain-based agent that prevents information leakage and provides a secure clinical data management model. The proposed DeepBlockShield implements a horizontal security system that prevents data leakage in the surface web environment and a vertical management system between the deep web and the surface web. The agent performs authentication to determine access rights to clinical data, and users can be divided to researchers and administrators according to their rights. Data analysis requests are passed through the agent, then the request and response for clinical data analysis are recorded Mathematics 2021, 9, 1069 3 of 16 into the blockchain. It enhances security by wrapping it asynchronously through a web interface.
This paper is structured as follows: in Section 2, previous studies are reviewed. In Section 3, the architecture design of the proposed system is explained. In Section 4, experiments are analyzed. In Section 5, conclusions are given.

Related Work
In general, the blockchain model ensures transaction transparency by allowing anyone to access data. Therefore, there is a risk of leakage when using clinical data through blockchain. In addition, data is anonymized through hash encryption. However, there is a risk of information leakage due to the transparency and re-identification of the data. Research is underway on access control to address the data leaked problem and anonymization approaches to protect information in the process of data disclosure and utilization. Table 1 shows a summary of the work involved.

Purpose
List Summary Privacy Protection [12,[15][16][17][18][19] Personal data management platform focused on personal information protection Access Control [18][19][20][21][22][23] Address data protection and privacy access control issues Blockchain Architecture [15,17,18,24,25] Guaranteed data integrity and non-repudiation through public verification based on blockchain technology First, various studies were conducted on the definition and importance of deep web data. Bergman et al. [5] quantified the size and importance of deep web content and extracted quality and relevance to search users. They defined the deep web and suggested how to navigate deep web content in search engines. Hu, Vincent C. et al. [7] proposed an access control model by evaluating the rules for the environment related to the properties of subjects and objects, tasks and requests. It supports a flexible approach to implementing access control policies that are limited only to the computational language and the abundance of available attributes.
In order to solve the problem of data access to personal information, Zyskind et al. [16] conducted a study on the control and management of user data through agents and the storage and access control of data using blockchain blocks [23]. Maymounkov et al. [21] utilized distributed hash tables to solve data protection and privacy access control issues [22]. Kaaniche et al. [20] proposed a method of enhancing security through encryption/signing of data to be shared by encryption based on hierarchical IDs to protect privacy and ensure continuous data availability. Liang et al. [24] proposed a blockchain-based data source architecture to provide tamper-resistant records, enabling transparency of data responsibility in the cloud, and improving the privacy and availability of source data. Rantos et al. [25] proposed a blockchain-based consent management system in which data subjects can exercise their rights for data processing with the goal of meeting the General Data Protection Regulation (GDPR) requirements for personal information protection in IoT environments. Fatokun et al. [17] proposed a patient-centric application that allows patients to manage medical records using blockchain. It enhances security including privacy protection and reinforces interoperability to support data exchange between different healthcare providers. Jabarulla et al. [18] proposed a decentralized patient-centered image management approach as an efficient data sharing of medical big data in an unreliable environment using blockchain and IPFS (Inter Planetary File System) technology. Wehbe et al. [19] proposed a safe management and efficient data integration model using blockchain and AI for the Electronic Healthcare Records (EHR) platform. It effectively tracks the use of patient data and securely maintains data provider ownership through patient-centric access control.
In addition, Mercer [12] proposed a cryptographic protocol designed not to allow individuals to be specified by mixing public keys that can be accessed without identifying the identity of private signers to address the anonymity problem of the blockchain. Kosba [15] proposes a decentralized smart contract system that maintains transaction privacy from the public's point of view without transparently storing transactions to protect transaction privacy.

Blockchain Agent Based Secured Clinical Data Management Model
In this subsection, we describe a data management model that can prevent information leakage while expanding the availability of clinical data in the deep web environment. This paper proposes a blockchain-based DeepBlockShield model that implements secure sharing of clinical data ( Figure 2). The proposed model adopts a two-way user verification and asynchronous information provision methodology to enhance the security of clinical data.
Mathematics 2021, 9, x FOR PEER REVIEW 4 of 17 using blockchain and AI for the Electronic Healthcare Records (EHR) platform. It effectively tracks the use of patient data and securely maintains data provider ownership through patient-centric access control.
In addition, Mercer [12] proposed a cryptographic protocol designed not to allow individuals to be specified by mixing public keys that can be accessed without identifying the identity of private signers to address the anonymity problem of the blockchain. Kosba [15] proposes a decentralized smart contract system that maintains transaction privacy from the public's point of view without transparently storing transactions to protect transaction privacy.

Blockchain Agent Based Secured Clinical Data Management Model
In this subsection, we describe a data management model that can prevent information leakage while expanding the availability of clinical data in the deep web environment. This paper proposes a blockchain-based DeepBlockShield model that implements secure sharing of clinical data ( Figure 2). The proposed model adopts a two-way user verification and asynchronous information provision methodology to enhance the security of clinical data. DeepBlockShield is functionally composed of a verification module, authorization management module, request management module, and role-based function control module. First, the verification module verifies the validity of user access with records between agent and blockchain. Second, the authorization module classifies researchers/administrators according to the agent's permission. Third, the request management module DeepBlockShield is functionally composed of a verification module, authorization management module, request management module, and role-based function control module. First, the verification module verifies the validity of user access with records between agent and blockchain. Second, the authorization module classifies researchers/administrators according to the agent's permission. Third, the request management module records the request information and analysis results in the blockchain through the agent and provides the asynchronously wrapped outcomes through the interface. Fourth, the role-based function control module approves/rejects analysis request contracts and requests and configures contract items that confirm the results of medical information.

Separated Access Control Module for Data Security
The proposed model constructs a data-separated agent between the surface web and the deep web as shown in Figure 3 above for the security of clinical data. For the individual management of personal data, blockchain is implemented in an off-chain state. The agent grants a permission to use data through permission control for the improvement of data security. A user is able to request access permission as an agent, using the interface. For this, he is required to provide information needed for user validation such as name, department and email address. Then, once the user information is verified, the administrator allocates the access permission to the agent and generates a smart contract on the blockchain, entering permitted user information. The proposed approach edits and prepares a block structure to manage such permission and records. The block structure according to the proposed scheme is shown in Table 2 below.
Mathematics 2021, 9, x FOR PEER REVIEW 5 of 17 records the request information and analysis results in the blockchain through the agent and provides the asynchronously wrapped outcomes through the interface. Fourth, the role-based function control module approves/rejects analysis request contracts and requests and configures contract items that confirm the results of medical information.

Separated Access Control Module for Data Security
The proposed model constructs a data-separated agent between the surface web and the deep web as shown in Figure 3 above for the security of clinical data. For the individual management of personal data, blockchain is implemented in an off-chain state. The agent grants a permission to use data through permission control for the improvement of data security. A user is able to request access permission as an agent, using the interface. For this, he is required to provide information needed for user validation such as name, department and email address. Then, once the user information is verified, the administrator allocates the access permission to the agent and generates a smart contract on the blockchain, entering permitted user information. The proposed approach edits and prepares a block structure to manage such permission and records. The block structure according to the proposed scheme is shown in Table 2 below.

Category
Information Description

Common Previous Hash
The hash value of the block positioned right before the blockchain.

Time Stamp
Stores data at the time when a contract is generated, and access permission is approved.

Research ID
Allocates a unique ID on the researcher joining a blockchain network.

Researcher
Research Period Stores a period on the researcher's request information. Target clinical data Saves the diagnosis code.
Variable Saves a data variable name requested by the researcher based on the CDM catalogue data.

Common Previous Hash
The hash value of the block positioned right before the blockchain.

Time Stamp
Stores data at the time when a contract is generated, and access permission is approved.

Research ID
Allocates a unique ID on the researcher joining a blockchain network.

Researcher
Research Period Stores a period on the researcher's request information. Target clinical data Saves the diagnosis code. Variable Saves a data variable name requested by the researcher based on the CDM catalogue data.
Free-Text Stores information on analysis methods by supporting a composite data type, e.g., data analysis request code, other information being generated at analysis request.

Admin Approval Authority
Allocates a unique ID on the hospitals joining a blockchain network. Expresses information in the institutions holding information on data field names.
Allocates institution IDs in sequence when joining a network.

Analysis Results
A URL revealing analysis results. An access to the site prohibited after an elapse of certain time even though information is leaked.

Authorization Management Module for Role-Based Smart Contract Configuration
The agent grants right for usage through the authorization management module. It is granted in a differentiated fashion depending on the sharing of clinical data. An agent checks the user's differentiated information permission and automatically generates transactions while creating a smart contract. In other words, smart contracts are managed according to the roles granted through the agent. In addition, it is able to mediate transactions and store and verify all records. As shown in the Figure 4, a blockchain platform builds a data-separated network for an agent-based security management system through the authorization management module. Modules are divided into roles: researcher, admin, and data scientist, and grant authority.

1.
Researcher; The researcher belongs to the hospital. Through the agent, clinical data analysis can be requested based on CDM catalog data. Furthermore, by entering the data analysis request code, the researcher enters information on the analysis method desired by the researcher. Finally, the researcher enters the study period for how long the data will be used.

2.
Admin; The admin manages the network and assigns a unique ID to hospitals that have joined the blockchain network through an agent. Research can be approved, modified, or canceled based on the information requested by the researcher. In addition, the information analyzed by the data scientist is finally confirmed and the analysis results are provided to the user through the agent.

3.
Data scientist; Data scientists have direct access to medical data and check and analyze the data the researcher wants based on the research request information approved by the admin.
Mathematics 2021, 9, x FOR PEER REVIEW 6 of 17 Free-Text Stores information on analysis methods by supporting a composite data type, e.g., data analysis request code, other information being generated at analysis request.

Admin
Approval Authority Allocates a unique ID on the hospitals joining a blockchain network. Expresses information in the institutions holding information on data field names.
Allocates institution IDs in sequence when joining a network.

Analysis Results
A URL revealing analysis results. An access to the site prohibited after an elapse of certain time even though information is leaked.

Authorization Management Module for Role-Based Smart Contract Configuration
The agent grants right for usage through the authorization management module. It is granted in a differentiated fashion depending on the sharing of clinical data. An agent checks the user's differentiated information permission and automatically generates transactions while creating a smart contract. In other words, smart contracts are managed according to the roles granted through the agent. In addition, it is able to mediate transactions and store and verify all records. As shown in the Figure 4, a blockchain platform builds a data-separated network for an agent-based security management system through the authorization management module. Modules are divided into roles: researcher, admin, and data scientist, and grant authority.

Researcher;
The researcher belongs to the hospital. Through the agent, clinical data analysis can be requested based on CDM catalog data. Furthermore, by entering the data analysis request code, the researcher enters information on the analysis method desired by the researcher. Finally, the researcher enters the study period for how long the data will be used.

Admin;
The admin manages the network and assigns a unique ID to hospitals that have joined the blockchain network through an agent. Research can be approved, modified, or canceled based on the information requested by the researcher. In addition, the information analyzed by the data scientist is finally confirmed and the analysis results are provided to the user through the agent. Under such an approach, approved nodes are only allowed to join a network. A blockchain consists of a 'validator node' and 'user node'. In the former, a network is managed through consensus. Table 3 below states the attributes of authority nodes. 'A_ID' is issued when joining a network and used in checking the creation of a transaction. A ledger is used when all nodes share the same information to check data. The database includes an ID and validation key which are needed to gain access to the external database. The authorization node is given to manage personal information on smart contracts. Table 3. Attributes of Authority Nodes.

A_ID
Issued through authentication when first joining the network. Block creation and authentication permission. Creates a transaction using A_ID.

Ledger
All authorities share the same contents. History of smart contracts related to the use of personal information by all nodes.

Database
Stores information for database connection. ID and authentication key to access DB provided by institutions Smart Contract The management and provision of personal information through smart contract Creates new smart contracts as needed A user node is a researcher node requesting medical information. Table 4 explains user node attributes. 'U_ID' is issued when joining a network and used in executing a transaction. 'R.I' includes the information on the researchers in Table 2 requested by the user. In addition, data analysis request codes and other information generated at analysis request are entered. A smart contract is a computer protocol designed to register, edit, read and delete medical information.

U_ID
Issued through personal information authentication when joining the network Blockchain registration and identifier role when sending personal information.
Signing with U_ID when requesting smart contract privacy.

R.I
The R.I contains the researcher information in Table 2 requested by the user Enters the variable name requested by using the variable used. Data analysis request code, other information generated when requesting analysis Smart Contract The ability to manage personal information Registration, correction, reading, deletion Figure 5 reveals a flow of a user's joining of node and authorization. Users register their personal information and affiliation. Once they are verified, they join a network. Then, they can access additional services through an agent. 'U_ID' is used to gain access to services and set smart contract requests. Users check subscription information through the agent and their access permission by confirming service rights. The agent verifies user information registered on the blockchain through the user information stored in the database and 'U_ID' permits access and provides additional services. Such validation information is entered into the blockchain services  'U_ID' is used to gain access to services and set smart contract requests. Users check subscription information through the agent and their access permission by confirming service rights. The agent verifies user information registered on the blockchain through the user information stored in the database and 'U_ID' permits access and provides additional services. Such validation information is entered into the blockchain services through the agent. In addition, integrity and effectiveness are validated with hash values between nodes by requesting the utilization of information. The validated data are confirmed with the analysis results whose validation has been proven with the requester's personal key. The ADMIN's registration is also processed just as with the user validation.

Management of Smart Contract-Based Clinical Data Analysis Request and Role-Based Feature Control
To support the utilization of clinical data and records management, an agent uses a smart contract-based analysis request management module and a role-based feature control module. In the analysis request management module, analysis is requested as illustrated in the Figure 6. According to the figure, once a user logs in through a web interface, user validation is executed through the agent and blockchain. Once the validation is complete, the validation details are recorded through a smart contract. The validated user requests analysis on clinical information. The information requested through the web interface is transmitted to an agent in a JSON format. Then, the agent performs validation to check if the target information exists in the medical database. Once such validation is complete, the details are recorded through the blockchain. After that, if data exist, they are analyzed through a data scientist as shown in Figure 3. The blockchain records the institution which performed such analysis and analysis time and results through a contract. The blockchain encrypts the results and sends them to the agent. Then, the agent provides wrapped results visualized in an asynchronous manner through the VIEW LAYER, using a web interface. The information is readable with the user ID, and the analysis results are protected from a third party. The pseudo-code (Algorithm 1) for user verification is as follows: if U is Admin, then return A if A is not Null, then exist is true else if U is Researcher, return B if B is not Null, then exist is true return exist; Figure 6. Analysis request management process diagram.
The role-based function control module can create a smart contract through the permission granted through the permission management module. The contract scenario is shown in Figure 7 below. The role-based function control module can create a smart contract through the permission granted through the permission management module. The contract scenario is shown in Figure 7 below. The information on analysis request is transmitted to the authority node. The authority node verifies the request information records of the user node. For the utilization of validated data, a transaction from the authority node is requested and validated. Once a user agrees to the use of data, the information requested by the group node is analyzed. The provided results can be checked by the requester's private key. The validator node manages the access to a network by the user node and group node. It handles all transactions on the network and stores and validates transaction history, guaranteeing integrity. The information on analysis request is transmitted to the authority node. The authority node verifies the request information records of the user node. For the utilization of validated data, a transaction from the authority node is requested and validated. Once a user agrees to the use of data, the information requested by the group node is analyzed. The provided results can be checked by the requester's private key. The validator node manages the access to a network by the user node and group node. It handles all transactions on the network and stores and validates transaction history, guaranteeing integrity. A smart contract used by the user node holds request and editing contracts. Information can be requested through each contract. Table 5 shows the user contract information. In terms of the registration of user contracts, contracts are implemented, using 'U_ID', time stamp, clinical data catalogue and organizational information. In a validator node, utilization is requested by the user node according to the catalogue. In terms of editing, the catalogue information registered by the user upon request is edited by executing a contract. Concerning deletion, request-related records and registration information are deleted.  Table 6 shows the information of the Admin contract. In terms of the registration of ADMIN contracts, contracts are implemented, using 'A_ID', time stamp, approved group information and requested clinical data. The group node requests the utilization of personal information through the registered data. In terms of information request, after confirming consent with information from the ADMIN through an agent, a data analyst analyzes the information. Using hash values of the data received after requesting 'A_ID' and results, results can be verified. Catalog data re-request information

Experimental Results
In this section, we implement and experiment the proposed agent-based clinical data management model.

Experiment Setup
In this paper, a private blockchain was constructed based on the PoA consensus algorithm. The correlation between block generation cycle and size and delay time was analyzed to verify stability. In order to perform the experiment, we (1) adjust the number of authority nodes and the ratio of malicious transactions, and (2) compare the delay time by block size. The agent configuration for the experiment is DB: PostgreSQL, Nodejs: 10.16.3, OS: Ubuntu 16.04, and the block chain configuration is Go: Go1.12.9, Geth: 1.9.3-stable, RAM: 8 GB, OS: Ubuntu 16.04. Table 7 shows the development environment used to implement the model.   Both users and admin are able to enter and check the information through the web interface. It sends the information on each process to the blockchain in a JSON format, using a REST method, and a contract is automatically created. In terms of research approval, the encrypted addresses of basic information on the research and user information are stored in blocks. Once the admin approves the analysis request, the query needed for analysis is requested to the user. Then, the user enters the desired catalogue and query through the web interface. The information is entered into blocks through the query request. Then, contract changes can be checked according to individual results. However, if attempting to cancel the research, all details will be deleted. Analysis request information and time records will only remain.

Blockchain-Based Information Distribution Management Delay Time Analysis
In terms of model performance assessment, a quantitative assessment on the time delayed by the time of creation and block-generation time by the block size and number of nodes is performed. In addition, qualitative assessment on confidentiality, availability and non-repudiation is conducted through a security review.
In our experiments, we measured the delay time by block-generation and TPS. Delay time refers to the time taken for a request to be responded to while TPS represents the number of transactions per second. TPS is calculated by dividing the number of transactions included in the latest block by the block creation cycle. We created 300 transactions per second to measure the model's performance. A block generation interval means the Both users and admin are able to enter and check the information through the web interface. It sends the information on each process to the blockchain in a JSON format, using a REST method, and a contract is automatically created. In terms of research approval, the encrypted addresses of basic information on the research and user information are stored in blocks. Once the admin approves the analysis request, the query needed for analysis is requested to the user. Then, the user enters the desired catalogue and query through the web interface. The information is entered into blocks through the query request. Then, contract changes can be checked according to individual results. However, if attempting to cancel the research, all details will be deleted. Analysis request information and time records will only remain.

Blockchain-Based Information Distribution Management Delay Time Analysis
In terms of model performance assessment, a quantitative assessment on the time delayed by the time of creation and block-generation time by the block size and number of nodes is performed. In addition, qualitative assessment on confidentiality, availability and non-repudiation is conducted through a security review.
In our experiments, we measured the delay time by block-generation and TPS. Delay time refers to the time taken for a request to be responded to while TPS represents the number of transactions per second. TPS is calculated by dividing the number of transactions included in the latest block by the block creation cycle. We created 300 transactions per second to measure the model's performance. A block generation interval means the time taken for a new block to be generated. Table 8 shows the block processing time with TPS and latency. As a result of the performance measurement, the longer the block generation cycle, the longer the delay time. However, there is no significant difference in TPS throughput. The block generation cycle is a more important factor than TPS when there are not many transactions. This is because the transaction speed is affected by the block generation cycle. In other words, 50ms is the best block generation cycle.
As a result of measuring network latency by block size, network latency increases as the size increases, while scalability improves. Therefore, the block size is set in consideration of delay time and scalability. Table 9 shows the delay time for each block size. In the detailed options of the blockchain, the proposed model has an average block generation time of 5 s and a transaction processing rate of 300 tps per second. In terms of a block size, if a transaction is requested in the user/validator node, the requested data is only searched. The output values received includes the statistics or results of the application. Then, VIEW through which information can be read is provided through the web interface. In fact, clinical data and analysis results are stored in the database outside the blockchain. Therefore, network speed is kept constant by setting the block size of a model to '1M' in consideration of a rapid increase in the number of transactions due to a low scaling issue for the block size. Table 10 shows the specific options for each block. The block generation cycle is the time until the next block is generated. This paper investigates network delay time by block generation interval/block size and finds an optimum size to generate an appropriate network. In conventional blockchain, when the block generation interval was short, data validation time decreased. Therefore, total validation time drops, having a negative effect on reliability. In the proposed model, however, validation reliability is related to the number of authority nodes. In other words, if the number of validation nodes rises, the data validation time also increases. According to the proposed model, a validator chosen based on identity trust, is able to block malicious attacks through block generation, editing and validation. Such a validator proposes and generates blocks. The generated blocks are verified between validators to check data integrity. The Figure 9 below reveals a model comprising three validation nodes and a model with eight different validation nodes. It also compares differences in the time spent to create 1000 blocks. The block size was set to 0.5 M and 1 M.  Figure 9 counts the generation of thousands of blocks and displays the time the contract was requested and completed. It was created within 9 s on both 0.5 M and 1 M blocks. When eight nodes are configured, as with conventional three-node configuration, only three nodes are selected for validity testing. Therefore, there were no changes in overall performances. In a three-node model, however, when an error occurs in two nodes, a network is shut down. In an eight-node model, on the contrary, even though an error is found in four nodes, the network functions normally. Figure 10 compares the performance of models using different consensus algorithms under the same conditions (three nodes, block size 1 M). In addition, it shows the block generation time according to the consensus algorithm. The proof of authority (PoA) consensus algorithm is a model optimized for a private net. Since consensus is reached by few authority nodes, it is far faster than the proof of work (PoW) consensus in terms of transaction processing and block generation. In addition, the block generation time is kept almost constant in the PoA algorithm. In the PoW algorithm, on the contrary, as the number of blocks rises, processing time considerably increases.  Figure 9 counts the generation of thousands of blocks and displays the time the contract was requested and completed. It was created within 9 s on both 0.5 M and 1 M blocks. When eight nodes are configured, as with conventional three-node configuration, only three nodes are selected for validity testing. Therefore, there were no changes in overall performances. In a three-node model, however, when an error occurs in two nodes, a network is shut down. In an eight-node model, on the contrary, even though an error is found in four nodes, the network functions normally. Figure 10 compares the performance of models using different consensus algorithms under the same conditions (three nodes, block size 1 M). In addition, it shows the block generation time according to the consensus algorithm. The proof of authority (PoA) consensus algorithm is a model optimized for a private net. Since consensus is reached by few authority nodes, it is far faster than the proof of work (PoW) consensus in terms of transaction processing and block generation. In addition, the block generation time is kept almost constant in the PoA algorithm. In the PoW algorithm, on the contrary, as the number of blocks rises, processing time considerably increases. under the same conditions (three nodes, block size 1 M). In addition, it shows the block generation time according to the consensus algorithm. The proof of authority (PoA) consensus algorithm is a model optimized for a private net. Since consensus is reached by few authority nodes, it is far faster than the proof of work (PoW) consensus in terms of transaction processing and block generation. In addition, the block generation time is kept almost constant in the PoA algorithm. In the PoW algorithm, on the contrary, as the number of blocks rises, processing time considerably increases.

Discussions for Security Review with Blockchain Agent
A leak of clinical data can evolve into a privacy breach. Therefore, confidentiality, availability and non-repudiation are reviewed on the features, which are important in terms of stability such as information access permission settings and encryption of shared information.

1.
Confidentiality In authority nodes, information is requested to the database configured in an off-chain format, using the data keys requested through user validation. Then, the results are verified with the ID given by the authority node. Then, the encrypted analysis results of the requested data can be checked through the web interface. If data are hacked, encrypted results are only leaked. Unless the encrypted private key granted through the agent is available, analysis results cannot be read. In addition, they are deleted from the database after the elapse of a certain period of time, enhancing confidentiality.

2.
Availability The proposed model stores user information in the agent and blockchain as well as through the web interface, allowing authorized members only to access it. In fact, an unauthorized user is not permitted to join the agent and blockchain. In the proposed model, information sharing on a closed network is performed through the blockchain. In the blockchain, validation nodes in which identity is guaranteed through the PoA consensus algorithm are only authorized to create and validate blocks. Even if malicious users attack the services, data cannot be forged or modified because they have no authority of data validation. Therefore, actual network damage is minor. In all nodes, furthermore, authorized validators are only able to validate and extend transactions in a quick and easy fashion.

3.
Non-repudiation In the proposed model, concerning the use of clinical data, related information (who, when, what, how) is stored in blocks when a transaction is requested. Then, a validator checks the transaction, and the transaction information is shared through the ledger owned by the network members. In other words, the history of access to personal information is clarified, allowing the information provider, hospitals, or governmental institutes to check the details.

Conclusions
With the development of artificial intelligence, remote medical services and research collaboration with common data are activated. However, the scope of data utilization is limited due to the leakage and abuse of personal sensitive information in clinical data. In this paper, we propose a blockchain-based clinical data management model called DeepBlockshield for preventing information leakage between the deep web and the surface web. The proposed model performs validation of user access and its authorization. Moreover, it can safely provide the analytic results between researchers. It is based on asynchronous data provision and indirect information sharing through the interaction between the blockchain and the agent. As a result, it not only prevents information leakage of medical records, but also innovatively improves interoperability and accessibility in the clinical research data.
The proposed model is designed to be applied to organizations, companies and hospitals where information protection is necessary. It is important to continuously improve the blockchain and data management on closed networks. In addition, further research is necessary to establish the distributed medical research networks based on data standardization. In future research, we intend to further study techniques to defend against attacks of agents.