1. 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.

2. Proposed System

2.1. 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.

Figure 1. DynamiChain network service based on blockchain and health examination of big data.

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.

2.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.

Table 1. Specific system function list.

Function Classification	Function Contents
Data Provider’s App	Basic account functions (log in, create account, etc.) My examination history ledger My examination data (raw data and statistical data) Dynamic consent rule settings
Data Utilizer’s App	Basic account functions Input health examination results data function Data provider list management Data providers’ examination history management ledger Data providers’ examination data sharing usage history management ledger Request for data provider data function Data provider data request management function (applicable and non-applicable)
Blockchain System	Health examination data hash storage function Sync smart contract with real-time dynamic consent function settings Smart contract and blockchain ledger
Blockchain Admin Web	Channel management Peer node management User account management Blockchain data sharing history ledger management

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.

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.

2.3. 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).

Figure 2. Three main functions of the proposed dynamic consent algorithm.

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-of-hospital 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.

Table 2. Contents of the three-level classifications of consent data types.

Classification	Contents
Basic	Serial number, Sex, Age, Smoking Status, Drinking Status, Height, Weight, Waist
Out-of-hospital-level tests	Body Water, Protein, Minerals, Body Fat Amount, Weight, Bones and Muscle Amount, BMI, Body Fat Ratio, InBody Score, Abdomen Fat Ratio, Internal Organ Fat Level, Fat-free Mass, Basal Metabolism, Obesity Index, Recommended Calorie Amount, Body Parts’ Muscle Analysis (Right Arm, Left Arm, Body, Right Leg, Left Leg), Body Parts’ Fat Analysis (Right Arm, Left Arm, Body, Right Leg, Left Leg), Body Parts’ Body Water Analysis (Right Arm, Left Arm, Body, Right Leg, Left Leg), Body Parts’ Cell Water Analysis (Right Arm, Left Arm, Body, Right Leg, Left Leg), Body Parts’ Cell-free Water Analysis (Right Arm, Left Arm, Body, Right Leg, Left Leg), Cell-free Water Ratio, Phase Angle
Hospital-level tests	Cholesterol, Triglycerides, HDL Cholesterol, LDL Cholesterol, Diastatic Hemoglobin, Diastatic Hemoglobin Before Meal, Protein in Urine, Serum Creatinine, AST, ALT, Gamma GTP, Serial Number, Examination Date, Examined Institution, Sight (Left, Right), Blood Pressure (Systolic, Diastolic)

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.”

2.4. 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.

Figure 3. Proposed specific blockchain service process.

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.

This entry is adapted from the peer-reviewed paper 10.3390/app11041612