KR20240082234A - Method and apparatus for supporing secure medical data transactions based on blockchain in a communication system - Google Patents

Abstract

The present invention relates to a method and device for supporting secure medical data transactions based on blockchain in a communication system. Specifically, the present invention relates to a method and device for increasing the security of party verification of medical data by proving the identity of an individual user who trades medical data with a medical institution through a double transaction history in a blockchain network. will be.

Description

Method and device for supporting secure medical data transactions based on blockchain in a communication system {METHOD AND APPARATUS FOR SUPPORING SECURE MEDICAL DATA TRANSACTIONS BASED ON BLOCKCHAIN IN A COMMUNICATION SYSTEM}

The present invention relates to a method and device for supporting secure medical data transactions based on blockchain in a communication system. Specifically, the present invention relates to a method and device for increasing the security of party verification of medical data by proving the identity of an individual user who trades medical data with a medical institution through a double transaction history in a blockchain network. will be.

The importance of identity authentication in data transactions is quite high. Identity authentication plays a central role in all stages of transactions, and its importance is especially emphasized in areas where data is sensitive and high-value. Identity authentication is a key element in strengthening the security of the data transaction process. When transacting parties know each other's identities, risks such as unauthorized data access, theft, and fraud can be greatly reduced.

Existing centralized identity authentication systems have several vulnerabilities. These systems have a single point of failure and have limitations in protecting and controlling users' personal data. Medical data, in particular, requires higher levels of security and personal control due to its value and sensitivity. However, most medical data is currently stored on central servers in hospitals or other medical institutions, and patients do not have complete control over their medical data. As a result, the demand for individual data sovereignty is increasing, which is also becoming an obstacle to the development of medical data science.

Various embodiments of the present invention provide a new method for digital identity verification, a Bitcoin-based Decentralized Identity (DID) system, and medical data transactions through the same. The main purpose of the present invention is to overcome the limitations of existing centralized identity authentication systems and provide users with greater control and security over personal data. To achieve this, we use a Bitcoin-based DID system that allows users to own and control their digital identity. Various embodiments of the present invention enable safe data exchange through ECDH (Elliptic Curve Diffie-Hellman) encryption and ensure data integrity and confidentiality using AES-GCM (Advanced Encryption Standard Galois/Counter Mode). . Furthermore, various embodiments of the present invention provide a new way for individual patients to effectively manage their medical data and safely share it with other institutions or individuals as needed. Through this, patients can use their medical data to create economic value or have the opportunity to receive better medical services. Through Bitcoin Layer 2 solutions, even small amounts of medical data transactions can be processed quickly and efficiently. All of this aims to strengthen user privacy and data sovereignty, while fostering the advancement of healthcare data science and research.

Public Patent No. 10-2023-0092607 (private blockchain-based decentralized identity verification system)

The present invention aims to solve the following problems in order to solve the above-mentioned problems.

The purpose of the present invention is to provide a method and device for supporting secure medical data transactions based on blockchain in a communication system.

The purpose of the present invention is to provide a method and device for increasing the security of party verification of medical data by verifying the identity of individual users who trade medical data with medical institutions through double transaction details in a blockchain network. do.

The present invention provides a method and device that significantly improves security and reliability by introducing a decentralized identity authentication method to solve the problems of security vulnerabilities and single points of failure inherent in existing centralized identity authentication systems. The purpose.

The purpose of the present invention is to provide a method and device that allows users to directly manage and control their own data and identity.

The present invention aims to provide a method and device that can reduce legal risks for users and organizations while meeting regulatory requirements for data protection and personal information protection.

The purpose of the present invention is to provide a method and device that can enable fast and efficient data transaction and management by eliminating complex intermediate processes and establishing a direct data exchange and management mechanism.

The purpose of the present invention is to provide a method and device that allows more users to participate in data transactions at low cost by solving this problem through a highly scalable Bitcoin layer 2 solution.

The present invention provides a method and device that can ensure safe transmission of data by utilizing advanced encryption technology such as ECDH (Elliptic Curve Diffie-Hellman) to enhance security in the process of encrypting and decrypting data. For the purpose.

According to various embodiments of the present invention, in a method of operating a server in a communication system, the server includes a transceiver, a memory, and a processor, information on a patient terminal and a first cryptocurrency wallet of the server, and information on a first cryptocurrency wallet of the patient terminal. 2 exchanging cryptocurrency wallet information by the transceiver; Transmitting, by the transceiver, one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network; Receiving, by the transceiver, a request message for the transaction information related to the two logics in the first cryptocurrency wallet from a hospital terminal - Decentralized Identifier (DID) of the patient terminal is the first password Containing a first address of a currency wallet and a second address of the second cryptocurrency wallet; Comprising the step of transmitting, by the transceiver, a response message containing the transaction information of the first cryptocurrency wallet related to the two logics to the hospital terminal, and the first address of the first cryptocurrency wallet and the first 2 The validity of the DID is proven based on the common presence of one transaction information related to the two logics for transmitting the set amount of cryptocurrency and OP_RETURN to the second address of the cryptocurrency wallet, and the OP_RETURN is sent when creating the transaction. A method is provided in which the signature data of the server is information that is blank without inserting the signature data in a predetermined location or inserting other data instead of the signature data.

According to various embodiments of the present invention, in a method of operating a patient terminal in a communication system, the patient terminal includes a transceiver, a memory, and a processor, a server, information on a first cryptocurrency wallet of the server, and information on the patient terminal. exchanging information of a second cryptocurrency wallet by the transceiver; Transmitting, by the transceiver, one transaction information related to two logics for receiving a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network; Generating, by the processor, a key pair of a random private key and a random public key based on the Elliptic Curve Integrated Encryption Scheme (ECIES) method for each communication instance; Encrypting medical data of the patient terminal by the processor using an Elliptic Curve Diffie-Hellman (ECDH) shared key calculated from the random private key of the patient terminal and the public key of the hospital terminal; Transmitting the encrypted medical data along with the random public key of the patient terminal to the hospital terminal by the transceiver based on decentralized identification information (Decentralized Identifier, DID) of the patient terminal, wherein the DID is Includes a first address of the first cryptocurrency wallet and a second address of the second cryptocurrency wallet, and an amount set in the first address of the first cryptocurrency wallet and the second address of the second cryptocurrency wallet The validity of the DID is proven based on the common existence of one transaction information related to the two logics for transmitting the cryptocurrency and OP_RETURN, and the OP_RETURN is the signature data of the server at the predetermined location when creating the transaction. A method is provided where the information is emptied without inserting or other data is inserted instead of the signature data.

According to various embodiments of the present invention, a server in a communication system is provided that includes a transceiver, a memory, and a processor, and the processor is configured to perform a method of operating the server according to various embodiments of the present invention.

According to various embodiments of the present invention, in a patient terminal in a communication system, a server is provided that includes a transceiver, a memory, and a processor, and the processor is configured to perform a method of operating the patient terminal according to various embodiments of the present invention.

The present invention can provide a method and device for supporting secure medical data transactions based on blockchain in a communication system.

The present invention can provide a method and device for increasing the security of party verification of medical data by proving the identity of an individual user who trades medical data with a medical institution through a double transaction history in a blockchain network. .

The present invention provides a method and device that significantly improves security and reliability by introducing a decentralized identity authentication method to solve the problems of security vulnerabilities and single points of failure inherent in existing centralized identity authentication systems. You can.

The present invention can provide a method and device that allows users to directly manage and control their own data and identity.

The present invention can provide a method and device that can reduce legal risks for users and organizations while meeting regulatory requirements for data protection and privacy.

The present invention can provide a method and device that can enable fast and efficient data transaction and management by eliminating complex intermediate processes and establishing a direct data exchange and management mechanism.

By solving this problem through a highly scalable Bitcoin layer 2 solution, the present invention can provide a method and device that allows more users to participate in data transactions at low cost.

The present invention provides a method and device that can ensure safe transmission of data by utilizing advanced encryption technology such as ECDH (Elliptic Curve Diffie-Hellman) to enhance security in the process of encrypting and decrypting data. can do.

The effects of the present invention are not limited to those mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

1 illustrates a communication system according to various embodiments of the present invention.
Figure 2 shows a block diagram of the configuration of a patient terminal and a hospital terminal according to various embodiments of the present invention.
Figure 3 shows a block diagram of the configuration of a server according to various embodiments of the present invention.
Figure 4 shows an example of a server operation method according to various embodiments of the present invention.
Figure 5 shows an example of a method of operating a patient terminal according to various embodiments of the present invention.
Figure 6 shows an example of ION DID recorded in Bitcoin according to various embodiments of the present invention.
Figure 7 shows an example of a personal identity authentication history record using OP_RETURN according to various embodiments of the present invention.
Figure 8 shows an example of an ecosystem for collecting and utilizing medical data according to various embodiments of the present invention.
Figure 9 shows an example of an appropriate balance of data utilization and protection according to various embodiments of the present invention.
Figure 10 shows Bitcoin's identity authentication (ION), small amount transmission/reception and payment (Lightning Network), asset issuance (Taro), and more various smart contracts (BIP-119, Liquid Network, RGB, etc.) according to various embodiments of the present invention. An example of a technology that realizes scalability based on decentralization and security is shown.
Figure 11 illustrates an example of an API model and incentives for data interoperability according to various embodiments of the present invention.
Figure 12 shows an example of a process for simply logging in, authenticating, and transmitting and receiving assets and data only by recognizing a QR code according to various embodiments of the present invention.
Figure 13 illustrates an example of selective data sharing according to various embodiments of the present invention.
Figure 14 shows an example of an additional service utilizing data in conjunction with a data wallet according to various embodiments of the present invention.
Figure 15 shows an example of a function for issuing actual patient data to a data wallet according to various embodiments of the present invention.
FIG. 16 illustrates an example of a process for generating medical data from selected patients for reliable research by medical researchers according to various embodiments of the present invention.
Figure 17 shows an example of data utilization according to various embodiments of the present invention.
Figure 18 shows an example of increased consent for data sharing due to increased compensation for data and reduced risk of personal information infringement according to various embodiments of the present invention.
Figure 19 shows an example of a governance protocol according to various embodiments of the present invention.
Figure 20 shows an example of a data collection and compensation system according to various embodiments of the present invention.
Figure 21 shows an example of a compensation system based on data collection and utilization according to various embodiments of the present invention.

Hereinafter, with reference to the attached drawings, embodiments of the present invention will be described in detail so that those skilled in the art can easily implement the present invention. The present invention may be implemented in many different forms and is not limited to the embodiments described herein.

1 illustrates a communication system according to various embodiments of the present invention.

Referring to Figure 1, the communication system according to various embodiments of the present invention includes a patient terminal 100, a management server 200, a hospital terminal 300, a wired/wireless communication network 400, and a blockchain network 500. Includes.

The patient terminal 100 is a terminal operated by a patient who can provide medical data in his or her name to the hospital. The patient terminal 100 is an electronic device that can transmit and receive information to the management server 200, the hospital terminal 300, and the blockchain network 500 through the wired/wireless communication network 400. . The patient terminal 100 includes an input device capable of inputting information, an output device capable of outputting information, a memory capable of storing information, and a device capable of transmitting and receiving information, such as computers, cellular phones, smart phones, and tablet computers. It may be an electronic device including a transceiver capable of performing operations on information and at least one processor capable of performing operations on information.

The management server 200 is a server operated by a business operator that provides a platform for performing medical data transactions between patients and hospitals. The management server 200 is an electronic device that can transmit and receive information to the patient terminal 100, the hospital terminal 300, and the blockchain network 500 through the wired/wireless communication network 400. The server 200 may be an electronic device that includes a memory that can store information, a transceiver that can transmit and receive information, and at least one processor that can perform operations on information.

The hospital terminal 300 is a terminal operated by a hospital that can collect medical data from the patient terminal 100 and pay compensation. The hospital terminal 300 is an electronic device that can transmit and receive information to the patient terminal 100, the management server 200, and the blockchain network 500 through the wired/wireless communication network 400. . The hospital terminal 300 includes an input device capable of inputting information, an output device capable of outputting information, a memory capable of storing information, and a device capable of transmitting and receiving information, such as computers, cellular phones, smart phones, and tablet computers. It may be an electronic device including a transceiver capable of performing operations on information and at least one processor capable of performing operations on information.

The wired/wireless communication network 400 provides a communication path through which the patient terminal 100, management server 200, hospital terminal 300, and blockchain network 500 can transmit and receive signals and data with each other. The wired/wireless communication network 400 is not limited to a communication method according to a specific communication protocol, and an appropriate communication method may be used depending on the implementation example. For example, when configured as an Internet protocol (IP)-based system, the wired/wireless communication network 400 may be implemented as a wired or wireless Internet network, and may include a patient terminal 100, a management server 200, and a hospital. When the terminal 300 and the blockchain network 500 are implemented as mobile communication terminals, the wired/wireless communication network 400 may be implemented as a wireless network such as a cellular network or a wireless local area network (WLAN) network.

Blockchain network 500 refers to a plurality of nodes operating based on blockchain technology. Here, blockchain technology is a distributed storage technology that uses a storage structure where blocks are connected in a chain form to store data to be managed in a plurality of nodes that make up a blockchain network. The blockchain network 500 converts transactions transmitted from at least one of the nodes constituting the blockchain network, such as the patient terminal 100, the management server 200, and the hospital terminal 300, into blocks based on a predetermined consensus algorithm. You can save it. Data stored in block form can be shared by a plurality of nodes constituting the blockchain network 500. In FIG. 1, the blockchain network 500 is expressed as a separate entity, but according to various embodiments of the present invention, the blockchain network 500 may be implemented as included in the management server 200. Depending on the implementation type, the blockchain network 500 may include a public blockchain network in which arbitrary nodes can perform consensus operations or a private blockchain network in which only predetermined nodes can perform consensus operations.

The consensus algorithms performed in the blockchain network 500 according to various embodiments of the present invention are: Proof of Work (PoW) algorithm, Proof of Stake (PoS) algorithm, Delegated Proof of Stage (DPoS) algorithm, and Practical Byzantine (PBFT) algorithm. Fault Tolerance) algorithm, Delegated Byzantine Fault Tolerance (DBFT) algorithm, Redundant Byzantine Fault Tolerance (RBFT) algorithm, Sieve algorithm, Tendermint algorithm, Paxos algorithm, Raft algorithm, Proof of Authority (PoA) algorithm, and/or Proof of Elapsed (PoET) Time) algorithm may be included.

According to various embodiments of the present invention, nodes in the blockchain network 500 may operate by a blockchain core package according to a hierarchical structure. The hierarchical structure is: a data layer that defines the structure of data handled in the blockchain network 500 and manages the data, verifies the validity of blocks, performs mining to create blocks, and fees paid to miners during the mining process. A consensus layer responsible for processing, an execution layer that processes and executes smart contracts, a common layer that implements and manages P2P network protocols, hash functions, digital signatures, encoding, and common storage, and various applications are created, processed, and managed. May include an application layer.

Figure 2 shows a block diagram of the configuration of a patient terminal and a hospital terminal according to various embodiments of the present invention.

Referring to Figure 2, the patient terminal 100 and the hospital terminal 300 according to various embodiments of the present invention include an input device 110, an output device 120, a transceiver 130, a memory 140, and a processor ( 150).

The input device 110 is connected to the processor 150 and can input information, etc. According to one embodiment, the input device 110 may input information received from another device connected to the wired/wireless communication network 400 through the transceiver 130. The input device 110 may include a touch display, keypad, keyboard, etc.

The output device 120 is connected to the processor 150 and can output information in the form of video/audio, etc. According to one embodiment, the output device 120 may output information received from another device connected to the wired/wireless communication network 400 through the transceiver 130. The output device 120 may include a display, a speaker, etc.

The transceiver 130 is connected to the processor 150 and transmits and/or receives signals. All or part of the transceiver 130 may be referred to as a transmitter, receiver, or transceiver. The transceiver 130 uses wired access systems and wireless access systems such as the IEEE (institute of electrical and electronics engineers) 802.xx system, IEEE Wi-Fi system, 3rd generation partnership project (3GPP) system, and 3GPP LTE (long term evolution) system. , can support at least one of various wireless communication standards such as 3GPP 5G NR (new radio) system, 3GPP2 system, and Bluetooth.

The memory 140 is connected to the input device 110, the output device 120, and the transceiver 130, and stores information input through the input device 110, information received through communication of the transceiver 130, etc. You can save it. In addition, the memory 140 is connected to the processor 150 and can store data such as basic programs for operation of the processor 150, application programs, setting information, and information generated by operations of the processor 150. . The memory 140 may be comprised of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. Additionally, the memory 140 may provide stored data upon request from the processor 150.

The processor 150 may be configured to implement the procedures and/or methods proposed in the present invention. The processor 150 controls the overall operations of the patient terminal 100 and the hospital terminal 300. For example, the processor 150 transmits or receives information through the transceiver 130. Additionally, the processor 150 writes and reads data into the memory 140. Additionally, the processor 150 receives information through the input device 110. Additionally, the processor 150 outputs information through the output device 120. Processor 150 may include at least one processor.

Figure 3 shows a block diagram of the configuration of a server according to various embodiments of the present invention.

Referring to FIG. 3, the management server 200 according to various embodiments of the present invention includes a transceiver 210, a memory 220, and a processor 230.

The transceiver 210 is connected to the processor 230 and transmits and/or receives signals. All or part of the transceiver 210 may be referred to as a transmitter, receiver, or transceiver. The transceiver 210 uses wired access systems and wireless access systems such as the IEEE (institute of electrical and electronics engineers) 802.xx system, IEEE Wi-Fi system, 3rd generation partnership project (3GPP) system, and 3GPP LTE (long term evolution) system. , 3GPP 5G NR (new radio) system, 3GPP2 system, and Bluetooth can support at least one of various wireless communication standards.

The memory 220 is connected to the transceiver 220 and can store information received through communication between the transceiver 220 and the like. In addition, the memory 220 is connected to the processor 230 and can store data such as basic programs for operation of the processor 230, application programs, setting information, and information generated by operations of the processor 230. . The memory 220 may be comprised of volatile memory, non-volatile memory, or a combination of volatile memory and non-volatile memory. Additionally, the memory 220 may provide stored data according to the request of the processor 230.

The processor 230 may be configured to implement the procedures and/or methods proposed in the present invention. The processor 230 controls the overall operations of the management server 200. For example, the processor 230 transmits or receives information through the transceiver 210. Additionally, the processor 230 writes and reads data into the memory 220. Processor 230 may include at least one processor.

Figure 4 shows an example of a server operation method according to various embodiments of the present invention. In the embodiment of Figure 4, the server includes a transceiver, memory, and a processor.

Referring to FIG. 4, in step S401, the server exchanges information of the first cryptocurrency wallet of the patient terminal and the server and information of the second cryptocurrency wallet of the patient terminal by the transceiver.

In step S402, the server transmits one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network by the transceiver. .

In step S403, the server receives a request message for the transaction information related to the two logics in the first cryptocurrency wallet from the hospital terminal through the transceiver. Decentralized Identifier (DID) of the patient terminal includes a first address of the first cryptocurrency wallet and a second address of the second cryptocurrency wallet.

In step S404, the server transmits a response message containing the transaction information of the first cryptocurrency wallet related to the two logics to the hospital terminal by the transceiver.

The DID based on the common presence of one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN to the first address of the first cryptocurrency wallet and the second address of the second cryptocurrency wallet. The validity of is proven.

The OP_RETURN is information where the server's signature data is emptied instead of inserted into a predetermined location when creating a transaction, or other data is inserted instead of the signature data.

According to various embodiments of the present invention, the OP_RETURN may include the DID of the patient terminal generated by the server instead of the signature data.

According to various embodiments of the present invention, decentralized identity information (DID) of the patient terminal and the hospital terminal may be managed by the server.

According to various embodiments of the present invention, in relation to the security of medical data transmission between the patient terminal and the hospital terminal, Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Diffie-Hellman (ECDH) are used to generate a shared key. Thus, data encryption and decryption can be performed by the processor without sharing the private key between the patient terminal and the hospital terminal. In addition, to ensure data integrity and confidentiality, AES-GCM (Advanced Encryption Standard Galois/Counter Mode) to encrypt the medical data before transmission of the medical data between the patient terminal and the hospital terminal will be performed by the processor. You can.

ECIES (Elliptic Curve Integrated Encryption Scheme) is a hybrid encryption system that combines the advantages of symmetric encryption and asymmetric encryption. It is widely used for secure data transfer, especially in environments with limited computational resources, such as smart cards or mobile devices. Here's an overview of how ECIES works:

(1) Key pair generation: The recipient generates an elliptic curve public-private key pair. The private key is kept secret, while the public key is shared with potential senders.

(2) Encryption process (by the sender): The sender, holding the recipient's public key, generates a temporary elliptic curve key pair specifically for this message. The sender then uses the recipient's public key and temporary private key to calculate the shared secret using Elliptic Curve Diffie-Hellman (ECDH). This shared secret is used for symmetric encryption and to derive the Message Authentication Code (MAC) key. The sender encrypts the message using a symmetric encryption key. MAC is calculated on the encrypted message for integrity and authentication. An encrypted message is sent to the recipient along with the MAC and the sender's temporary public key.

(3) Decryption process (by the receiver): The receiver uses its private key and the sender's temporary public key to calculate the same shared secret as the sender. From this shared secret, recipients generate identical symmetric encryption and MAC keys. The recipient checks the MAC to ensure the integrity and authenticity of the message. If the MAC is valid, the recipient uses the symmetric key to decrypt the message.

The advantages of ECIES are as follows:

(1) Security: Combines the security of public key encryption (for secure key exchange) with the efficiency of symmetric encryption.

(2) Efficiency: Elliptic curve cryptography allows smaller key sizes compared to other public key systems such as RSA, resulting in faster computation and reduced resource usage.

(3) Flexibility: ECIES can be used with a variety of elliptic curves, symmetric encryption methods, and MAC algorithms, so it can adapt to various security requirements.

ECIES is particularly effective at encrypting small messages or encapsulating keys (encryption keys used for symmetric encryption of large data sets). It is an important component of many modern encryption protocols and systems, providing a powerful and efficient means of securing communications.

Elliptic Curve Diffie-Hellman (ECDH) is a core consensus protocol that allows two parties to establish a shared secret over an insecure channel. It is an application of elliptic curve encryption. Here's a basic overview of how ECDH works:

(1) Key generation: Each party generates its own key pair: a private key (a randomly chosen number) and a public key (a point on an elliptic curve calculated from the private key).

(2) Public key exchange: The parties exchange public keys with each other. This exchange does not need to be secure. The public key is not secret.

(3) Calculating shared secret: Each party calculates the shared secret by combining the other party's public key and its own private key. This is done using the properties of elliptic curves and the mathematics of the Diffie-Hellman problem. The advantage of ECDH is that both parties arrive at the same shared secret independently. This is because combining one party's public key and the other party's private key produces the same value as combining the other party's public key and the first private key.

(4) Utilization of the shared secret: The shared secret can then be used to encrypt further communications using a symmetric encryption algorithm.

ECDH is widely used in a variety of encryption protocols, including SSL/TLS for secure web communications and a variety of secure messaging applications. The strength of ECDH is that it is based on an elliptic curve discrete logarithm problem that is difficult to solve with current technology. This makes ECDH a strong choice for secure key exchange, especially in environments where processing power and bandwidth are critical. As with all cryptographic protocols, the security of ECDH depends on proper implementation, including the selection of a secure elliptic curve and protection against various types of cryptographic attacks.

AES-GCM (Advanced Encryption Standard Galois/Counter Mode) is a widely used encryption algorithm to protect sensitive data. It combines the Advanced Encryption Standard (AES) algorithm and Galois/Counter Mode (GCM) operation. An overview of the main features is as follows:

(1) AES (Advanced Encryption Standard): AES is a symmetric key encryption algorithm. That is, the same key is used to encrypt and decrypt data. It has become the de facto standard for secure data encryption worldwide due to its security strength and efficiency. AES supports key sizes of 128, 192, and 256 bits.

(2) GCM (Galois/Counter Mode): GCM is an operating mode of symmetric key encryption block cipher. It is a stream encryption mode that provides both confidentiality through encryption and integrity through data reliability. GCM operates based on block ciphers by parallelizing the encryption process, speeding up the processing of long messages.

(3) Combination of AES and GCM: AES-GCM combines the AES algorithm and GCM mode to create a system that efficiently encrypts and authenticates data. This combination provides confidentiality through AES encryption and authenticated integrity through GCM's authentication capabilities.

(4) Function: In AES-GCM, data is encrypted through a series of operations on data blocks (typically 128 bits in size). GCM mode applies a counter to each block, ensuring that each block is encrypted with a unique key. GCM also calculates authentication tags (a type of cryptographic checksum) that provide integrity checks for the data.

(5) Advantages:

Efficiency: Suitable for high-throughput environments due to the ability to process parallel data blocks.

Security: Provides strong data confidentiality and integrity.

Flexibility: Most commonly used with AES, but can be used with a variety of block cipher algorithms.

(6) Application: AES-GCM is widely used in secure communication protocols such as Transport Layer Security (TLS) and Internet Protocol Security (IPSec). It is also used in a variety of applications that require both encryption and data integrity, such as file encryption, secure data transfer, and virtual private networks (VPNs).

Implementation Considerations: Correct implementation of AES-GCM is critical to security. Mismanaging keys or nonces (numbers used once) can compromise cryptographic security. AES-GCM combines the advantages of AES encryption with the additional security and performance benefits of the GCM mode of operation, making it a powerful and efficient choice for modern encryption requirements.

According to various embodiments of the present invention, a server in a communication system is provided, including a transceiver, a memory, and a processor, and the processor is configured to perform the server operating method according to the embodiment of FIG. 4.

According to various embodiments of the present invention, a computer program configured to perform the method of operating a server according to the embodiment of FIG. 4 and recorded on a computer-readable storage medium is provided.

Figure 5 shows an example of a method of operating a patient terminal according to various embodiments of the present invention. In the embodiment of Figure 5, the patient terminal includes a transceiver, memory, and processor.

Referring to FIG. 5, in step S501, the patient terminal exchanges information of the server's first cryptocurrency wallet and information of the patient terminal's second cryptocurrency wallet with the server by the transceiver.

In step S502, the patient terminal transmits one transaction information related to two logics for receiving a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network by the transceiver. do.

In step S503, the patient terminal generates a key pair of a random private key and a random public key based on the Elliptic Curve Integrated Encryption Scheme (ECIES) method for each communication instance by the processor.

In step S504, the patient terminal encrypts the medical data of the patient terminal by the processor using an Elliptic Curve Diffie-Hellman (ECDH) shared key calculated from the random private key of the patient terminal and the public key of the hospital terminal. .

In step S505, the patient terminal transmits the encrypted medical data along with the random public key of the patient terminal to the hospital terminal by the transceiver based on the decentralized identifier (DID) of the patient terminal.

The DID includes a first address of the first cryptocurrency wallet and a second address of the second cryptocurrency wallet.

The DID based on the common presence of one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN to the first address of the first cryptocurrency wallet and the second address of the second cryptocurrency wallet. The validity of is proven.

The OP_RETURN is information where the server's signature data is emptied instead of inserted into a predetermined location when creating a transaction, or other data is inserted instead of the signature data.

According to various embodiments of the present invention, the OP_RETURN may include the DID of the patient terminal generated by the server instead of the signature data.

According to various embodiments of the present invention, decentralized identity information (DID) of the patient terminal and the hospital terminal may be managed by the server.

According to various embodiments of the present invention, in relation to the security of transmission of the medical data between the patient terminal and the hospital terminal, Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Diffie-Hellman (ECDH) are used to generate a shared key. Data encryption and decryption can be performed without sharing the private key between the patient terminal and the hospital terminal using . To ensure data integrity and confidentiality, AES-GCM (Advanced Encryption Standard Galois/Counter Mode) may be performed to encrypt the medical data before transmission of the medical data between the patient terminal and the hospital terminal.

According to various embodiments of the present invention, a server is provided in a patient terminal in a communication system, including a transceiver, a memory, and a processor, and the processor is configured to perform the server operating method according to the embodiment of FIG. 5.

According to various embodiments of the present invention, a computer program configured to perform the method of operating a patient terminal according to the embodiment of FIG. 5 and recorded on a computer-readable storage medium is provided.

Explains Bitcoin DID and data transaction technology.

Blockchain: Bitcoin, ION, Lightning, Liquid

Cryptography: ECDSA, ECDH, ECIES, AES-GCM, PBKDF2, SHA256

Below, Hippocrat Bitcoin DID and Hippocrat data economy will be described.

In various embodiments of the present invention, Hippocrat is an operator of the management server 200 and corresponds to an exemplary name for a business operator that provides a platform for performing medical data transactions between patients and hospitals. That is, in various embodiments of the present invention, Hippocrat is the management server 200, the operator of the management server 200, or an operator who provides a platform for performing medical data transactions between patients and hospitals, or, It can be interpreted by replacing it with various embodiments of the present invention.

One. Hippocrat Bitcoin DID

1.1. Authentication system of existing platform

There are three main participants in the authentication system of the existing platform.

An individual who is the sovereign of identity (an example is a patient). A certification agency that proves the identity of the above individual (a certification agency can be an operator of a medical data transaction platform, etc., examples of such certification agencies) An example would be Hippocrat as an enemy name. An example would be an external organization attempting to verify the identity of the above individual (Hospital).

Let's look at an example situation in which authentication may be requested. For example, the patient is a rare disease patient and possesses genomic data that is of great medical research value. Accordingly, the hospital wants to purchase the above patient's genomic data for research. In order for these transactions to take place on the platform, the patient must prove that the identity (and data) registered on the platform on which the transaction takes place is theirs.

Existing platforms store patient identity information in a certifying authority, for example, in a centralized database. Patients do not retain or manage their identity data. Hospitals can also verify patient identity through a centralized database. As such, the existing authentication system is security-risky (there is a single point of failure called a centralized database), and individual data sovereignty does not exist.

1.2. Hippocrat DID authentication system

Hippocrat's authentication system also has three participants. There is an individual (e.g., patient) who is the sovereign of the identity and owns it directly as a DID. There is a decentralized database (e.g. Bitcoin) that proves that the above DID was issued by Hippocrat. There are external organizations (e.g. hospitals) that want to verify an individual's DID and a decentralized database.

We assume that the example situation in which authentication is requested is the same as 1.1 above. First, DID is where an individual directly owns identity verification data. DID is largely composed of three types according to the standards set by W3C.

Id: This is the unique identifier of the corresponding DID.

Key Pair: Consists of public key and private key.

Service: Identity data to be included in DID.

DID uses ECDSA, an asymmetric key structure called public key-private key, to prove identity.

The secret key is owned directly by the individual rather than in a centralized database (e.g., on a disk on a local device), and a signature is created based on that secret key. On the other hand, the public key is publicly recorded in the DID. The signature created with the above private key can be authenticated with the public key. Therefore, when a specific individual authenticates that he or she is the owner of the DID, he or she creates a signature with his or her own private key, and then the other party who wishes to verify his or her identity creates the signature with his or her public key disclosed in the DID. This can be done by checking validity. In other words, individuals can become full owners of their identity data, increasing data sovereignty while eliminating concerns about single points of failure.

ION DID is a Bitcoin Layer 2 DID service that complies with these standards. When creating a DID, proof of work is performed on the layer 2 ION network, and then 10,000 DIDs are recorded on the Bitcoin mainnet in batches. ION is an open source to which major developers from big tech, such as Microsoft and Block, who have high technical skills and a high understanding of Bitcoin, are contributing. Accordingly, various embodiments of the present invention utilize ION DID and directly contribute to the open source.

However, ION DID alone is not enough. For example, the ION DID service, that is, the personal identity verification data, requires proof that the ION DID has been issued according to various embodiments of the present invention (of course, only a mark is left, and the personal data and secret key are stored by the individual) do). Naturally, this is performed in a way that nothing is stored in the centralized database according to various embodiments of the present invention. It is not sufficient to simply put, for example, the sentence “This is a DID issued by a specific platform operator (e.g., Hippocrat).” ION DID can only prove that the owner of the DID with the corresponding ID belongs to the person holding the private key. In other words, if a malicious attacker creates a new ION DID that copies and includes the above content, owns the private key locally, and signs it, it will be impossible to distinguish whether the ION DID issued according to various embodiments of the present invention is authentic. . For this purpose, in the case of identity verification, a decentralized database that can be authenticated must be used.

Hippocrat can utilize Bitcoin, a decentralized system, as a decentralized database that can be authenticated. The technical process is as follows.

One. Create Bitcoin wallets for Patient and Hippocrat.

2. In Hippocrat's Bitcoin wallet, two logics are sent as one transaction: OP_RETURN* and the amount set in the Patient Bitcoin wallet, for example, sending a very small amount of Bitcoin.

3. Include Patient and Hippocrat's Bitcoin wallet addresses in Patient's ION DID.

4. Hospital checks whether a transaction record of 2 exists in the Bitcoin address of Patient and Hippocrat included in Patient ION DID.

5. Through this, it can be confirmed that the Patient ION DID is a valid DID issued by Hippocrat.

Figure 6 shows an example of ION DID recorded in Bitcoin according to various embodiments of the present invention.

OP_RETURN is a technology that can store small-sized data in Bitcoin blocks. Bitcoin also uses a public key-private key signature authentication structure (Elliptic Curve Digital Signature Algorithm, ECDSA), but it intentionally creates an invalid transaction by not entering the data required for the signature when creating a transaction. The reason why you have to pay a fee to create an invalid transaction is because you can freely store data equal to the size of the signature data that was not included in the signature above. Here, “This is a DID issued by Hippocrat” can also be entered. In this way, by using the Bitcoin blockchain as a decentralized database for the Hippocrat DID authentication system, a high level of defect-freeness and censorship resistance can be achieved. Through the proposed method, the economic incentive for malicious attackers to create fake ION DIDs, including the above, can disappear even if they are not patients. This is because the ION DID contains the real patient’s Bitcoin wallet address.

Even if a malicious attacker creates an ION DID by modifying only the Bitcoin wallet address to his own Bitcoin address, it is revealed to be fake because there is no Hippocrat's OP_RETURN transaction history on the Bitcoin blockchain.

An example of a transaction recorded in an ION DID and a Bitcoin block is shown in Figure 6.

Figure 7 shows an example of a personal identity authentication history record using OP_RETURN according to various embodiments of the present invention.

(1) The DID issuer (transaction input) is the wallet of the DID manager according to various embodiments of the present invention and bears the transaction fee.

(2) The DID registry (Tx output 1) marks OP_RETURN as humanDid.

(3) The DID owner (Tx output 2) is the DID owner, and can be proven to be a human patient with an OP_RETURN transaction in the data wallet according to various embodiments of the present invention. It is a structure that can be issued to multiple owners at once (for example, Tx Output 3, Tx Output 4, Tx Output 5, ...).

Figure 7 shows an example of a Hippocrat authentication history record (e.g., Bitcoin Block Explorer) using OP_RETURN. In this way, the present invention can provide a DID that secures a high level of security and scalability among existing DIDs.

2. Hippocrat data economy

2.1. Technical issues for building a blockchain data economy

The service to be implemented based on Bitcoin DID according to various embodiments of the present invention is a decentralized data trading market. Although patient medical data has a significant value, it is rare for patients to own and manage it themselves, and therefore, there is not much revenue generated from it yet. These medical data are stored and managed on the centralized server of each hospital. For this reason, patient sovereignty over my data is becoming a major obstacle to the development of medical data science.

To solve this problem, various embodiments of the present invention implement the following data trading market.

(One) Alice, a patient, brings her medical data from the hospital.

(2) Bob, a researcher at the hospital, checks the metadata of Alice's medical data and announces his intention to purchase it for 1 BTC.

(3) When Alice agrees, Bob transfers 1 BTC to Alice's Bitcoin address written in Hippocrat DID.

(4) After confirming the deposit in Bitcoin, Alice encrypts and transmits her medical data.

(5) Bob receives the encrypted data and decrypts it.

There are two technical issues here. In relation to a highly scalable Bitcoin payment solution for encryption/decryption and safe transmission/reception of data, various embodiments of the present invention safely encrypt/decrypt and transmit/receive data through ECDH-based multi-signature technology in accordance with the DIDComm standard. Additionally, we provide payment solutions through Liquid and Lightning networks for highly scalable Bitcoin payments.

2.2. Security: Cryptographically secure data transmission and storage technology

ECDH (Elliptic Curve Diffie-Hellman), like ECDSA (Elliptic Curve Digital Signature Algorithm), utilizes an asymmetric key pair generated based on the elliptic curve. ECDH's DH (Diffie-Hellman) is Diffie-Hellman, which utilizes a key exchange algorithm to calculate one shared key with two asymmetric key pairs. In other words, two DID holders according to various embodiments of the present invention can create a shared key that can be used for encryption without sharing their respective secret keys.

The process is as follows.

(One) This is a situation where Alice is sending medical data to Bob.

(2) Alice and Bob are holders of DID according to various embodiments of the present invention, and hold an asymmetric key pair generated by EC (each person's public key is public in the DID, and only each person knows the secret key).

(3) Alice calculates the shared key A with Bob's public key and her own private key.

(4) Bob calculates the shared key B using Alice's public key and his own private key.

(5) When calculated in the same way as above, shared key A = shared key B.

(6) This shared key is one symmetric key.

(7) Alice encrypts data using AES-GCM, a symmetric key encryption algorithm standard.

(8) Bob decrypts the data with the calculated shared key.

In this way, each secret key is held asymmetrically, but the shared key is calculated symmetrically. Even if the shared key is stolen, each person's private key has the advantage of not being stolen.

However, in actual communication, there is no need for Alice to calculate the shared key A directly with her secret key. You can use ECIES, a standard framework for data encryption delivery. In other words, you can do it in the following way.

(One) Alice generates an EC-based random key pair for each communication.

(2) Alice calculates the shared key from her random private key and Bob's fixed public key.

(3) When Alice encrypts data with a shared key and transmits it, she transmits it along with the random public key generated in 1.

(4) Bob decrypts the data by calculating the shared key using the received random public key and his fixed secret key.

For security purposes, the transmitter uses a one-time random secret key rather than its own fixed secret key to further increase security. In conclusion, using the ECIES (Elliptic Curve Integrated Encryption Scheme) encryption communication framework utilizing ECDH, pure peer-to-peer data transmission is secure and secure through a DID key in the data trading market of various embodiments of the present invention. It can be implemented conveniently. This encryption technology can also be used when encrypting the mnemonic of a data wallet according to various embodiments of the present invention to pursue both convenience and security.

2.3. Scalability: Highly scalable payment through Bitcoin Layer 2

Bitcoin is the most decentralized and trustworthy blockchain, but it still lacks scalability for large numbers of transactions. It takes on average more than 10 minutes to complete a transaction, and a fee of more than 1 USD is required. If medical data is of sufficiently high value, it may be acceptable to use the mainnet for payment, but a highly scalable solution is essential to frequently trade medical data with small amounts of value.

Accordingly, various embodiments of the present invention support layer 2 solutions in addition to Bitcoin mainnet payment solutions. These solutions include Liquid and Lightning Network.

Liquid Network is a sidechain-based Bitcoin Layer 2 solution implemented by Blockstream, founded by Bitcoin Core developers. A sidechain is a type of independent blockchain that is based on its own consensus process and algorithm, but uses a method of pegging and unpegging layer 1 cryptocurrency (e.g. Bitcoin) to the sidechain. In other words, in the case of Liquid, conversion (peg and unpeg) between mainnet Bitcoin and Liquid Bitcoin is possible, so Liquid Bitcoin is utilized in the Liquid network. Similar to DPOS, this Liquid Network creates a block when 11 out of 15 nodes reach agreement, and also executes peg and unpeg. Security is secured by using keys stored in HSMs (hardware security modules). Additionally, a Bitcoin-based token economy can be implemented by allowing the issuance of tokens such as Ethereum's ERC20.

Lightning Network is currently the most widely adopted Bitcoin Layer 2 solution and is a state channel solution utilizing Bitcoin's multi-sig wallet. In order for Alice and Bob to send Bitcoin to the Lightning Network, they create a 2-of-2 multisig wallet that requires both parties' secret key signatures to create a transaction. Afterwards, when Alice and Bob send Bitcoin to the other party on the connected Lightning channel, they create an incomplete transaction signed with their respective secret keys. In this way, the possibility of malicious ledger manipulation is eliminated because the counterparty can execute the transaction on the Bitcoin mainnet as long as the other party has his or her signature on the transmitted transaction. After creating countless incomplete transactions in the Lightning Network, the final calculated balance is recorded as one on-chain transaction through a multi-sig wallet signature. There are other attack scenarios, such as a malicious user trying to sign past incomplete transactions to their advantage, but these can be prevented through hash time locks.

As such, various embodiments of the present invention can build a medical data token economy through secure data transmission and reception and support for Bitcoin-based payment solutions.

Figure 8 shows an example of an ecosystem for collecting and utilizing medical data according to various embodiments of the present invention.

The HUM project, which began in 2018, started with the vision of contributing to the personalization of medical services by establishing an environment where patient data can be collected and utilized transparently. In 2020, Rarenote was launched through Humanscape Inc., a partner development corporation, and so far, patient data has been secured for approximately 30,000 rare disease patients. In this process, patients' various health data collection details were recorded on the blockchain, and more than 7,200 transactions have occurred to date. Additionally, by sequentially launching the pregnancy and child-rearing service Mommy Talk in 2020 and the clinical research data platform Rare Data in 2022, we have gained a better understanding of problems that can arise in the process of generating and utilizing data. However, in order for the 'health data collection and utilization ecosystem' to be established in its original meaning, it must be able to meet the three items below.

(One) Building a patient-centered data utilization environment

(2) Decentralized governance and open collaboration structure

(3) A sustainable incentive model that considers not only patients but also governance participants

Through this process, the project team needs a blueprint for a new structure that goes beyond the limits of governance and goals revealed through the existing HUM project white paper. In fact, other than one or two services from partner development company Humanscape Inc., it is difficult to find cases around the world where health data is meaningfully utilized based on blockchain. This is because major organizations and institutions that are capable of generating data or are already collecting a lot of data have interests that make it difficult for them to readily participate in blockchain projects where a specific private company has the lead. Accordingly, in various embodiments of the present invention, the HUM project team presents a blueprint for ‘building a health data collection and utilization ecosystem’ with a new identity called Hippocrat. Hippocrat means ‘the party of Hippocrates’ and is named after the ancient Greek physician Hippocrates.

The incentive model and governance provided in various embodiments of the present invention enable information subjects to have self-sovereignty over healthcare data on a more open and decentralized protocol, and allow medical institutions and organizations that utilize healthcare data to operate smoothly. We can help you cooperate. This can protect data subjects from privacy violations, build trust between individuals and institutions, and promote the use of data, which can lead to a variety of innovations that can improve health and improve quality of life.

For example, patients can receive customized health care using their healthcare data while minimizing the risk of personal information infringement, and can also expect profits generated from data utilization. Pharmaceutical companies or healthcare service providers can obtain data with sufficient consent from patients and use it to screen subjects for more efficient clinical trials or develop precision medical services. Medical institutions such as hospitals can expect compensation for providing sustainable data by proving that they have contributed to data creation while satisfying the high level of data rights required by data subjects.

To obtain healthcare data, the public healthcare system and its sustainability are important. Activation of the medical data transaction method presented in various embodiments of the present invention not only benefits individual stakeholders, but can also help increase financial resources donated to the public health care system of the country to which each information subject belongs. As such, various embodiments of the present invention can not only strengthen the rights of information subjects and individual stakeholders, but also contribute to a future in which more patients and stakeholders in the ecosystem around the world enjoy healthy lives.

The definitions and classification standards for healthcare data are diverse. Hereinafter, the classification method and concept of healthcare data used in various embodiments of the present invention will be described.

To the possibility of personal identification classification for

Most major countries, including the United States, include individual identifiability as an important criterion for data classification. In particular, the identifiability of medical data is important to prevent because it poses a risk of privacy infringement, but it can also be used to bring about new innovations that improve the health of patients and individuals by combining various valuable data. Therefore, a delicate approach is needed to maintain an appropriate line between protecting and utilizing personal information. The most representative method that follows this approach is the US HIPPA/HITECH method. This method presents basic principles regarding the protection and use of health information and classifies medical information into the three categories below. Medical information not included in this category is also basically subject to general laws related to personal information protection.

data type identifiability Requires patient consent for use Use for research purposes Protected health information (PHI) O O Available after IRB review Deidentified Health Information (DHI) X X freely available Limited dataset (LDS) X (somewhat relaxed conditions apply) X
(Exemption for purposes such as research) Possible after submission of agreement to prohibit data re-identification and IRB review

Protected health information (PHI)

Protected health information is created, collected, transmitted, and stored by medical institutions, payment organizations, and medical-related organizations subject to HIPPA, and includes an individual's (1) past, present, and future physical and mental health status, (2) health insurance information, (3) It is defined as individually identifiable health information, which is information about medical expenses, etc.

Protected medical information can only be used, corrected, or exported for purposes other than treatment with the consent of the patient, except in some exceptional cases such as public interest. Research institutions, etc. can use protected medical information for research purposes through the Institutional Review Board (IRB).

De-identified health information (DHI)

Non-identifiable medical information is recognized in two ways: 1) safe harbor method and 2) expert judgment method. The safe harbor method refers to a method of removing the 18 types of identifiers below. The subject of the expert judgment method is a person with appropriate knowledge and expertise in the fields of statistics and science regarding the possibility of identification or identification method. Even if the information is combined with other information, it can be recognized only when the risk of identifying an individual is judged to be very low and the reason and results are recorded in writing.

Organizations regulated by HIPAA are required to freely use or disclose non-identifiable medical information. If it is determined to be identifiable despite these measures, it is considered protected health information (PHI).

Examples of types of personal identifiers include: name, address, dates on the individual (date of birth, insurance subscription date, insurance termination date, death date, etc.), telephone number, vehicle registration number, fax number, device serial number and identifying information, email address. , online access addresses (URLs), social security numbers (SSN), Internet access (IP) addresses, medical record numbers, biological fingerprints or voiceprints), health insurance information, potentially personally identifiable photos, account information, and re-identification. Information proposed as information, certification/credentialing information, or other potentially recognizable information

Limited data sets (LDS)

Limited datasets are similar in that they are information in which identifiers have been removed from medical information like De-identified Health Information (DHI) following the Safe Harbor method, but more relaxed standards are applied to some date information (date of birth, Date of hospitalization, date of discharge, etc.), zip code, and residence (state, city) may be included.

Information users, such as researchers, are required to submit an agreement prohibiting re-identification of data containing information to prevent data abuse, and when information is used for specific purposes (research, public health, medical service provision), it is required to go through IRB even without the patient's consent. It is stipulated that it can be used later. In other words, it is a type that imposes the responsibility of re-identification on information users and instead makes it easier to utilize the information in a valuable way.

In the data content classification for

In addition to individual identification, the criteria for classifying data are diverse, including whether it can be structured, who and how it is created, the purpose of use, and the type of object. However, in various embodiments of the present invention, rather than applying strictly classified classification criteria or explaining all types in detail, representative types that have important meaning in terms of utility value are selected and introduced, and the method in which each data is used is introduced. We want to focus on helping you understand.

Clinical data

This is the most representative type of healthcare data, which includes patient information generated by medical institutions such as hospitals while conducting diagnosis, medication, testing, and surgery. Therefore, a wide variety of detailed items exist, ranging from structured test numerical data to medical records written in natural language, medical images and images (X-ray, CT, MRI, ultrasound, endoscopy, etc.).

When such information is stored electronically, it is called an Electronic Medical Record (EMR), and the entire medical information of an individual stored in several places is called an Electronic Health Record (EHR). Most clinical data is protected health information (PHI) at the time of creation, and by law, medical institutions have the obligation and responsibility to keep it safe, and access to and use of this data by organizations other than patients is strictly prohibited.

Data derived from clinical data includes claims data based on information submitted by medical institutions when billing insurance organizations. This includes the patient's personal information, diagnosis name, medication information, and test information. In the case of Korea, a single insurance system is adopted, and the Health Insurance Review and Assessment Service and the National Health Insurance Corporation are constructing and releasing public data based on the data of all citizens (Healthcare Big Data Open System, National Health Insurance Data Sharing Service) etc).

Omics data

It refers to a comprehensive data set that encompasses biological materials such as genome, transcriptome, proteome, metabolome, and microbiome. This biological material has unique characteristics for each individual, so it is expected that personalized medicine will become possible if data on this is accumulated and analyzed on a large scale.

Genomic data is the most representative omics data, and refers to data that expresses the genetic information recorded in DNA, which determines individual characteristics, as a base sequence by combining the letters A, T, G, and C like a ciphertext. In fact, analyzing genome data is like deciphering a ciphertext, and the main task is to analyze what differences are made between individuals depending on the single or multiple bases at a specific position. In particular, since more than 80% of rare diseases are caused by genetic mutations, it is important to decipher the code to identify the genes causing the disease.

Recently, with the development of machine learning and big data analysis technology, it has become possible to analyze genomic and various biomaterial data together with clinical data. This is being used to diagnose diseases early and discover markers (biomarkers) used to predict and measure treatment response.

Person-generated health data (PGHD)

This refers to data that includes data generated from various sensors such as wearable devices and mobile phones owned by patients or individuals without relying on external organizations, or self-posting or surveys posted on social services, etc. These data have the characteristic of being able to be collected on a regular basis in daily life without visiting a hospital.

Human-derived health data may seem somewhat unrelated to the disease, but when combined with clinical data and other data, it has the potential to lead to new discoveries related to the disease. In fact, there is a continued trend of recent attempts to actively utilize PGHD as real-world data (RWD) in clinical trials for new drugs.

Social Determinants of Health (SDOH)

Social determinants of health refer to data that affect health among external social and economic factors that are inherently determined, such as demographic information, social and political requirements, and climate and environment. An example of actually utilizing SDOH data is the Gravity Project. In this project, socio-economic factors (education, occupation, family, income, social safety), physical environment, health (smoking, eating habits, alcohol, sex life), and health care (access to medical institutions) are defined as major factors and determine their impact on health. The goal is to analyze the impact.

Research data

This corresponds to data generated when pharmaceutical and life science-related laboratories, pharmaceutical companies, and hospitals develop new treatments such as new drugs. Representative data include clinical trials and research results. Clinical data or omics data that has already been created can also be called research data if it is recycled or collected for research purposes.

For research data, it is essential to collaborate with various organizations to secure enough participants to conduct the study. Just as communication between people who speak different languages is not easy, communication and cooperation during the research process will be difficult if different organizations use different names or units for the same data. Therefore, research data is generally well structured and collected under uniform rules among institutions jointly conducting research. Standardization efforts such as the common data model (CDM) are continuing for integrated analysis of data within different hospitals or patient data accumulated through various studies.

Research data is generally designed to be collected in a scientifically rigorous and systematic manner and verified by academics and review agencies. In addition, before conducting research, the legality and suitability of data collection subjects and collection methods are reviewed by review committees such as IRB, so the quality of the data is high.

In addition, there is data, such as personal payment information, that is not significantly related to health in itself, but can be used meaningfully when combined with other healthcare data and analyzed. For example, if an individual has a regular payment history at a fitness center, the payment information may not seem related to health when viewed on its own. However, if a certain health-related figure improves or worsens, it is possible to predict changes in an individual's health index by analyzing it in relation to payment information.

In this way, data can become more valuable when combined with other types of data. Therefore, an important task for the future is to find out which data can be valuable when combined with commonly known healthcare data.

Figure 9 shows an example of an appropriate balance of data utilization and protection according to various embodiments of the present invention.

In this way, data is being used to improve health levels and create new breakthroughs in disease treatment. However, it is also true that actual results fall short of the astronomical amounts of investment and big data utilization technology promised so far. The main reasons for this are that there is not enough data that is 1. reliable, 2. collected over a long period of time, and 3. interconnected. In other words, the core of medical innovation is solving the quality and quantitative issues of data, which is the basis, rather than AI or big data technology. Below, we explain the challenges that must be solved to secure sufficient size and high quality medical data.

1. Balance between data protection and utilization

Type 1.

Personal medical information is one of the most sensitive types of personal information, and there is a tendency for it to be very strictly protected by law around the world. The most common protection measures are pseudonymization and anonymization, and in reality, it is very difficult or impossible to identify individuals with data that has been de-identified, thereby reducing damage from personal information leaks or abuse. De-identified data that has been determined to have been safely anonymized or pseudonymized may be freely used only for certain purposes, such as research for the development of new drugs and new treatments. In this way, major countries are enacting laws that allow data to be used more valuablely while minimizing the risk of personal identification.

However, it is inevitable that these personal information protection measures will act as a limitation in terms of value creation through the use of information. When data is combined with each other, it can be analyzed more richly and new value creation can be facilitated. However, in pseudonymized data, data values are abstracted or categorized. For example, 33 years old is expressed as 30s, 87kg is expressed as 80-90kg or 90kg, etc. Because this is different from the actual figure, it may be inappropriate depending on the purpose of using the data. Additionally, combining data often makes it possible to do things that couldn't be done with individual datasets alone, but data anonymization makes combining data very difficult.

Therefore, it is important to strike an appropriate balance between data utilization and protection.

2. Providing appropriate methods of obtaining consent and subsequent control

As explained previously, the data that can currently be used without separate consent from patients is limited to certain purposes such as research and statistical compilation, and the quality of the data being used is also compromised. In order to secure data as much as possible without these problems, you must inform and obtain consent from information subjects such as patients about the data items you want to collect, the purpose of use, and the conditions of use.

Type 1. Problems in securing consent

Obtaining consent in this way is the minimum requirement for legality from the perspective of an organization wishing to use data. Therefore, the institution will want to obtain patient consent on the condition that the data can be used without restrictions as much as possible. In other words, consent may be obtained in a way that does not sufficiently protect the information subject. In fact, in the EU (case law: Federation of German Consumer Organizations vs. Planet 49 case) and Korean judicial authorities (case law: sweepstakes entry ticket 1mm letter notice case), consent is given passively, such as consent through a pre-selected checkbox, or in a way that is difficult for the data subject to recognize. We believe that the consent being collected is not valid consent.

However, the reason for such ‘insufficient consent’ may not necessarily be due to the institution’s impure intentions. This may be due to the fact that the terms of service and privacy policy notices are written in extensive and difficult terms, making it difficult for most people to understand them. In addition, the form of obtaining consent by subdividing the contents in order to thoroughly protect personal information may paradoxically feel cumbersome to the individual, and for this reason, rather than making an effort to ensure that the contents of the terms and conditions are in the best interest of the patient, patients may insensitively request consent or non-consent. You may end up agreeing. In this way, even if the agency intended to protect personal information more thoroughly, the result may be insufficient consent.

Meanwhile, from the patient's perspective, the degree of understanding of what benefits there will be to the patient when data is used and what the potential risks are in this process can also be factors that influence securing consent. In other words, the greater the personal benefit expected from data use and the higher the level of understanding of data risks, the greater the likelihood of obtaining sufficient consent.

Therefore, it is important to obtain consent based on the information subject's judgment rather than coercion.

Type 2.

The U.S. Department of Health and Human Services (HHS) revised the Common Rule on January 20, 2020 to allow secondary use of data without additional consent, even if identifiable and not for research purposes, provided comprehensive consent is obtained on the premise of sufficient notice. allowed to do so. This is to achieve the positive effect of increasing the efficiency of research and the value of data use by saving the cost and time of obtaining consent from patients each time unless there are special risk factors. Additionally, since it is often only possible to consider reasonable purposes for use after collecting data, it may be efficient to collect data with consent for a somewhat comprehensive purpose.

However, in these cases, it is important to provide patients with access to all data use and disclosure history, as well as the right to withdraw consent to data use. Alternatively, data can be collected first, but at the time of actual use, the patient can confirm more details and consent to use (Opt-in), or withdraw consent (Opt-out) at any time even after consent has been given. There is also a way to provide a (Dynamic-consent) system.

In this way, obtaining sufficient consent in advance and ensuring the right to control data afterward is a very important factor in protecting personal information while creating value through data utilization. If this is realized, it will be possible to provide a positive experience in terms of information transparency and system trust, and this will gradually act as a natural expectation and become an essential factor for institutions to consider in securing patients and users, regardless of the legal aspect. will be. Therefore, a solution is needed that enables sufficient consent-based data management and use from the perspective of patients, institutions that want to use data, and institutions that manage data on behalf of patients.

3. Lack of incentives to share data

Major countries are enacting related laws to achieve a balance between personal information protection and data use by realizing patients' right to self-determination. A representative example is the 21st Century Cures Act in the United States. This law ensures that patients' medical information stored in medical institutions are mutually compatible and allows patients to access, exchange, and use their medical information in their desired applications. Failure to comply will result in a fine of up to $1 million per incident.

However, many medical institutions still share data electronically in a format that is difficult to read and use. In addition, it is a common phenomenon around the world that companies and researchers are legally restricted from sharing data even with patient consent, or are reluctant to provide data for data protection reasons even in countries where such laws do not apply.

In the case of Korea, the Ministry of Health and Welfare is also promoting My Healthway, a pilot service and legalization of my data in the medical field. According to recent reports, it does not force medical institutions to participate in patients' information transmission requests, but provides services to individuals and patients. It has been said that voluntary participation will be encouraged with the goal of improving quality. In addition, private companies other than medical institutions will be allowed to participate after 2024, which is still far from realizing the right to data self-determination in the strict sense.

In this way, there are limits to realizing the right to data self-determination due to legal obligations or punishment. What is more ideal is for data self-determination to be realized through the voluntary motivation of stakeholders within the ecosystem. However, a survey by the National Academy of Medicine found that health care executives say they lack economic drivers for data sharing and are concerned about losing competitiveness by sharing data externally. In fact, measures for data sharing, such as data structuring and standardization, quality control, and data storage, mainly involve costs and expertise of the medical institution that generates the data, while the benefits are likely to be seen by the institution that utilizes the data. . Due to this incentive imbalance, it is not easy for data generating organizations to voluntarily participate.

Measures needed to share data

(One) Data structuring and standardization

In the case of clinical data, the terminology used in unstructured text formats is often inconsistent, and the task of structuring it so that computers can read and understand it

Additional work to standardize data types, terms, and formats to facilitate collaboration among multiple people through data sharing

Add search metadata to check for duplicate data and discover combinable data

(2) Quality Management

Review and correction of cases where a patient with multiple diseases simultaneously enters only the diagnosis required for insurance claims, and information is unintentionally omitted or incorrect information is entered during the handwriting process.

Efforts to resolve issues with accuracy of measuring equipment and inconsistent results depending on skill level of equipment use

(3) data storage

Storage and management of up to 200GB of genomic data per person

Technology to store, manage, and transmit data with small capacity while making it easy to reanalyze

4. Lack of understanding and reliable records of data rights

What needs to be considered along with incentives is forming a consensus on the rights to data. There is no major disagreement over the fact that the right to self-determination of data should belong to the patient, the subject of the information. However, ownership, a concept closely related to incentives, is not so simple. The concept of ownership is generally applied only to tangible goods such as real estate or goods. Concepts that grant exclusive rights to intangibles include intellectual property rights such as copyrights and patents, but these rights are recognized only when creative efforts are made. Therefore, copyright, which is an exclusive right, is recognized only in the case of databases in which editing efforts have been made, rather than the information or data themselves.

It takes a lot of effort to create patient medical data. In addition to the simple data itself, which is primarily measured through equipment of medical experts and medical institutions, there is also a lot of data generated by judgment or interpretation based on expertise, such as diagnosis or positive/negative. Additionally, in order for data to be shared and used meaningfully, the measures mentioned above must be taken. In some cases, additional effort is required to combine different data. The dataset created through all of these processes is the result of editing at a considerable cost and with the considerable expertise of medical experts.

In addition, it cannot be overlooked that medical data has a public nature as it is supported by the medical insurance system or a medical system created with public funds. Therefore, rather than guaranteeing exclusive profit and usage rights to a specific entity, ensuring non-rivalry, that is, the characteristic that consumption by one entity does not reduce the opportunity for other entities to consume, is more beneficial to the public as well as the information subject. Data can be used more actively.

There is still no way for these records of ownership, data sharing and use to be recorded in a reliable manner and for all stakeholders to freely access and utilize these records.

Figure 10 shows Bitcoin's identity authentication (ION), small amount transmission/reception and payment (Lightning Network), asset issuance (Taro), and more various smart contracts (BIP-119, Liquid Network, RGB, etc.) according to various embodiments of the present invention. An example of a technology that realizes scalability based on decentralization and security is shown.

Previously, we explained what healthcare data is needed for the development of health and medicine, such as the development of new drugs. In order to secure sufficient data of good quality, challenges such as balancing the protection and use of personal information, securing sufficient consent, incentives for data sharing, understanding data rights, and reliable recording must be addressed.

In order to solve the above-mentioned problems, various embodiments of the present invention propose a collaboration protocol for healthcare data through open standards and a patient's right to data self-determination, decentralized governance, and a sustainable incentive model on the Bitcoin layer. Hereinafter, methods for realizing this goal will be described.

Realization of patients’ data sovereignty

To date, the business model of many Internet companies is to develop better advertising algorithms and create highly profitable advertising products by utilizing user data accumulated on the company's internal servers. This business model allowed users to use services conveniently and inexpensively, but in return, users had to give up much of their sovereignty over their information and data.

The non-profit global organization MyData Global (mydata.org) proposed the concept of 'MyData' as an answer to this problem and defined it as follows. This expanded into the area of identity and became the background for the birth of a technology field called self-soverign identity (SSI), which allows people to use the Internet with sovereignty over their personal identity and data.

(One) A new practical movement to change the current organization-centric system to a human-centric system in the management and processing of personal data.

(2) Personal data as a resource that individuals can access and control

Various embodiments of the present invention share the same philosophy as My Data and Self-Sovereign Identity and focus on realizing it in the healthcare field. In particular, in the healthcare field, decisions by the information subject are essential to sufficiently protect individuals and enable reasonable use of data. If this is realized, innovation in internet and digital technology can finally accelerate in the healthcare field.

Data ecosystem with incentives and open collaboration

From the creation of healthcare data to its added value and utilization, it involves cooperation not only from information subjects such as patients, but also from various stakeholders such as medical institutions, public institutions, and companies. In all of these processes, costs are invested to produce added value. Therefore, without appropriate incentives (financial compensation or value-added services, etc.) that can satisfy the motivations of each stakeholder, this cooperation will not be sustainable.

Various embodiments of the present invention allow data to be traded and utilized according to the information subject's right to self-determination, and when monetary compensation occurs in this process, compensation is distributed to stakeholders who contributed to the creation and processing of data, including the information subject. Provides protocols. In addition, all information in the distribution process, from data creation to utilization, is transparent and recorded on the blockchain without risk of forgery or falsification, creating an environment in which sufficient cooperation can be achieved without relying on the trust of third parties.

These protocols are also determined not by a specific centralized entity, but by an open cooperation system. Tools and services used by users are developed with open standards and open source, and policies and standards are decided through open discussion and voting by participating governance members. This method can enable global cooperation to improve human health.

Figure 11 illustrates an example of an API model and incentives for data interoperability according to various embodiments of the present invention.

Hash: Ensure data integrity

People often misunderstand that medical data itself is recorded on the blockchain. As explained above, blockchain inevitably cannot contain a lot of data because it costs money to constantly maintain copies of the same content. Therefore, blockchain is only suitable for use for the purpose of containing the minimum amount of information that requires reliable storage for truly important data, such as assets or identities.

This is easy to understand if you think about the records left in the real estate register. In the real estate register, you can check current and past records to clearly determine ownership of real estate. We can also change actual ownership by simply changing the register records without exchanging actual real estate. Various embodiments of the present invention also use blockchain to record the distribution history of the information subject of medical data, the content of the medical information contained, the creator, the actual location of the data, and the sharing target.

If so, you may think that since the actual data content itself is not uploaded to the blockchain, the blockchain will not be able to prevent forgery and falsification of the data content. Here, a cryptographic technology called ‘hash function’ is needed. The hash function has the characteristic that even if a very minor change occurs in the input data, the result value (hash value) is completely different. For example, when I entered the original file, 57 came out and this was recorded in the blockchain, but if the hash value of the data I received is 58, different from the hash value recorded in the blockchain, I can be sure that the original file has been forged or altered. . Even if just one letter is changed or a space is added in the original data, a completely different hash value is produced. Through this method, you can check whether the original data has been forged or altered and make a transaction without recording the actual data on the blockchain.

input data Hash value (using SHA-256 hash function) Hippocrat 174ae7c5faf856241800d4156a303d97252b1a015c141b4022b9e0b87712f9f5 Hippocrat ec4a395e1d365143981a6f2474971f94f033e3eac1f4c7777833668f350abf3a Hippocrat 30583e5b90579f8eb47ab12aa5bd3753bfbd73d18c4512ef9525e4beef5869f4 Hippocrat1 b8fa3200c96fa507857bf7850b8e32e73ecd253ba3c69b22ea57af410d98c618

Self-sovereign identity and my data

Self Sovereign Identity (SSI) is a new model proposed to represent an individual's identity on the Internet, and the technologies to realize it are Decentralized Identifier (DID) and Verifiable Credentials (VC). ) was adopted as a web standard by the W3C in July 2022.

Self-sovereign identity technology does not allow individuals to trust a company (or be forced to agree to terms and conditions in order to use the service) and entrust their information to be managed on their behalf, but rather allows the information subject to maintain complete control over his or her information. In this state, companies are required to ask data subjects for consent to access and use information.

Then, the paradigm can be changed so that information subjects proactively share only essential information and control its use. In addition, previously, hackers could steal tens to millions of personal information by hacking a centralized server just once, but now they can only attack one person at a time, which reduces the motivation for hacking and ultimately makes personal information more effective. A protected environment can be created.

Based on self-sovereign identity technology, Hippocrat can realize the MyData concept, which allows information subjects to exercise their right to self-determination by including not only personal identity information but also medical data.

The MyData model can solve the problems of overly complex API models and platform models without incentives for data interoperability.

DID: Identifier for self-sovereign identity

Until now, our identity on the Internet could only be identified in the form of an account within a service server provided by a specific company. Because of this, there was the inconvenience of having to create a new account every time you signed up for a new service, and having to repeat the same process for each service when identity verification was required. Therefore, the method of logging in with an account of a large service such as Google or Facebook was widely adopted, but this led to an overload of personal information on one server, deepening the risk of hacking. Additionally, the more you rely on a specific service, the more vulnerable your account becomes to the threat of being suspended or restricted at any time if it is 'deemed' to be in violation of the company's policies. This is clearly evident in the recent case where Paypal, an American simple payment service, attempted a policy that would impose a 'fine' of $2,500 on the accounts of users who do not comply with its policies.

DID provides a solution to these problems. DID is your own unique ID (identity identifier) that is created based on mathematics and cryptography without the help of a third party and can be freely used anywhere on the Internet. This is the same as assigning a unique number to all atoms in the universe, randomly selecting one of them, and being assigned an ID generated from that unique number and a password (private key) to control it. And personal accounts and personal information linked to those accounts are recorded on the blockchain, and the right to view and control them is given only to users who own the private key. This allows us to freely create and manage our identities without the help or control of governments or corporations. This method can be especially useful in the medical field that requires a high level of personal information protection, and records of identity and control rights can also be kept safe as long as all computers and the Internet connected to the blockchain do not disappear, so the present invention Self-sovereign identity required for various embodiments can be realized.

There are several types of DID depending on which blockchain it is recorded on, and various embodiments of the present invention use ION based on Bitcoin. ION is an open source DID protocol whose main supporters are Microsoft and Block, and can contain 10,000 DID records in one Bitcoin record. These features are suitable for various embodiments of the present invention that require sufficient scalability on top of Bitcoin's robust decentralization and security.

Verifiable Credentials (VC): Anything that proves who you are.

Birth certificates, college diplomas, passports, driver's licenses, employee ID cards, gym passes, hospital registration cards, prescriptions, etc. describe and prove certain facts about me. For example, if you go to a pharmacy and present a prescription, you can explain and prove which medicine was prescribed for which disease and by which doctor at which hospital. This allows pharmacists to prepare medicine with confidence that the prescription is appropriate. Additionally, you can prove that you actually received the prescribed medication through the medication receipt received from the pharmacy. If you collect these documents and submit them to the insurance company, you can receive insurance money based on proven records.

Verifiable Credential (VC) refers to specific information that explains and proves certain facts about me. The information contained in the VC includes the issuer (issuer's DID), the subject of the credential (information subject's DID), the claim to be proven (age, relationship, diagnosis, etc.), and the holder who stores this credential (holder's DID. Usually consists of the information subject and the holder are the same, but if a minor child is the information subject, the guardian may be the holder). And all of this information can be verified as to who issued it, whether it has been manipulated, or whether it has not expired or been cancelled.

All of the traditional physical credentials mentioned in the first example were susceptible to forgery, and many of them were difficult to verify over the Internet. To solve this problem, separate verification devices or verification agencies such as signatures or holograms existed, but they were incomplete in terms of personal information protection and had many limitations in terms of cost and technology for use on the Internet on a global basis. VC is issued on a blockchain that anyone can transparently verify, allowing verification on the Internet at a much faster rate and significantly reducing costs. Based on this possibility, DID and VC were developed with funding from the US Department of Homeland Security and others, and were adopted as open global standards in July 2022.

VC is also an essential element in realizing the collaborative healthcare data ecosystem proposed by various embodiments of the present invention. If data about a patient can be verified without an intermediary, the friction that occurs during the distribution and use of data can be minimized, creating a more active ecosystem.

Secure healthcare data exchange

As explained earlier, blockchain is appropriate to be used for the purpose of containing the minimum amount of information that is highly important and requires reliable storage, such as a register for assets or identity. However, some of the medical data may be recorded on the blockchain in the form of VC as identity information, but in the case of PGHD (reference), which can amount to several TB in hundreds of GB of genomic data, it is not realistic to store it on the blockchain, and that much A copy is not required.

Various embodiments of the present invention can transmit and receive data through ECIES (Elliptic Curve Integrated Encryption Scheme), a standard framework for data encryption delivery that utilizes ECDH (Elliptic Curve Diffie-Helman)-based multi-signature technology according to the DIDComm standard. let it be Using this technology, data is safely encrypted and decrypted and exchanged so that it cannot be opened by anyone other than the two parties explicitly connected for data exchange, without going through a separate intermediary server. What this means is that patients can safely exchange large amounts of data directly with medical institutions and data utilization organizations without relying on other institutions, and the data distribution channel can be improved very efficiently without the risk of personal information leakage. If you combine this with an appropriate incentive device, data trading becomes possible.

In addition, you can also consider using IPFS (InterPlanetary File System), a protocol for distributing and storing and sharing files. When a file is uploaded to the IPFS network, it is distributed and stored across multiple nodes, and a unique identifier (CID (Content IDentifier)) that connects the distributed files is created from the hash value of the file. If a specific large dataset about a patient is encrypted with the patient's public key, uploaded to IPFS, and the CID is issued in a VC, then when the patient shares the data with another organization, that organization verifies that the CID has not been changed and the original You can be sure that it is the same file as .

In addition to the method described above, secure data exchange can be implemented in various ways, and the methods to be adopted by various embodiments of the present invention are not limited to these. Of course, various embodiments of the present invention can be applied to various solutions in addition to the examples described above.

Figure 12 shows an example of a process for simply logging in, authenticating, and transmitting and receiving assets and data only by recognizing a QR code according to various embodiments of the present invention.

Data Wallet: Data

The data wallet according to various embodiments of the present invention is a data wallet that manages the information subject's identity, data received from institutions, and assets acquired through data sharing rewards, etc. The method of storing personal data in a data wallet is similar to storing a card key or receipt that can access the data, rather than storing the original data itself. It's like keeping not only cash or credit cards but also ID cards, membership cards, tickets, blood donation, card keys, receipts, etc. in your wallet and taking them out whenever you need them. Just as if you lose your wallet, you also lose everything inside it, the wallet owner has full control over it, and in other words, full responsibility also lies with the wallet owner. The same goes for data wallets.

Below, the core functions provided by the data wallet according to various embodiments of the present invention will be described. Most of the core functions are implemented based on open standards and open source, which means that instead of reinventing the wheel, we focus on adding added value that focuses on the problems that various embodiments of the present invention are trying to solve based on already well-proven technologies. It is for this purpose. This approach has the advantage of minimizing intentional and unintentional defects that can occur in new software while still enjoying continuous improvement and innovation in open standards. In addition, the final implemented data wallet application will also be released as open source, which will provide reliability by allowing anyone to transparently verify the newly written code in the data wallet according to various embodiments of the present invention, and based on this, new improvements will be made. This is so as not to block the possibility of building up innovation. Additionally, this method allows access to the assets and data contained in the data wallet according to various embodiments of the present invention through other data wallet applications preferred by the user.

Private key generation and management

The most basic function of the data wallet according to various embodiments of the present invention is to safely generate and store the private key required to access and manage one's assets and data and the identity identifier DID. Since the data wallet according to various embodiments of the present invention follows the BIP39 standard, its security is the same as the private key of most Bitcoin wallets and the mnemonic code generation method for recovering it. Therefore, data wallets according to various embodiments of the present invention basically provide Bitcoin wallet functions. For additional security of private key storage, you can also utilize the device's TEE (Trusted execution environment).

Connect, authenticate, log in

Once your DID is created, you can connect P2P with organizations that access data without an intermediary. All data and messages passed between them are end-to-end encrypted and cannot be viewed by anyone other than the parties involved. Using this method can minimize the risk of personal information exposure that occurs during the communication process.

The first connection is usually made by scanning a QR code or pressing a button for connection on the organization's application or website, then confirming information about the destination the user wants to connect to, request permissions, and data, and then approving it. If you connect once like this, it will be remembered as a trust relationship and the connection will be maintained unless one side terminates it.

If you think about the healthcare situation, hospitals generally require you to register as a new patient during your first visit. At this time, the patient presses the registration button and scans the QR code with his or her data wallet to receive a request to share legal identity such as name, resident registration number, photo, and gender to verify his or her identity. If the patient approves this, the hospital staff confirms the patient's identity from the patient's data wallet and then the patient is registered.

Because this method replaces login or other authentication methods, it eliminates the inconvenience of having to create and remember an ID and password for each service the user wants to connect to. Additionally, you can easily log in, authenticate, and send and receive assets and data simply by recognizing the QR code. In addition, by combining additional security measures such as PIN and biometrics with the private key in the data wallet application itself, it is effectively multi-factor authentication (MFA), which can achieve a much higher level of security than general login methods.

Referring to FIG. 12, through a data wallet according to various embodiments of the present invention, it is possible to easily log in, authenticate, and transmit and receive assets and data simply by recognizing a QR code.

Figure 13 illustrates an example of selective data sharing according to various embodiments of the present invention.

Data (VC) Management

When connected to a counterparty, such as a hospital, through a data wallet, various certificates or data can be sent to the user whenever the user requests it or whenever the other party deems it necessary. The main object of transmission from the data wallet according to various embodiments of the present invention is data issued in the form of a verifiable credential (VC).

In a typical scenario, when a hospital issues data such as medical records, it goes through an authentication process to confirm the patient's identity and then issues it in the form of VC to the patient's data wallet DID. Then, a notification and message will arrive asking if the data has been issued to the data wallet and whether to approve it, and after approval, the data can be checked. Unlike general cloud storage, all data is encrypted and stored using the user's encryption key.

The data issued in this way can be presented where necessary. For example, to use health care services using data, a QR code scan is requested, saying access to specific data is required to provide services to patients. When a patient scans a QR code, he or she can check detailed information about the service provider and conditions of use, including what data is being used, and if approved, the data is shared with the service provider. Then, the service provider verifies whether the hash of the data is the same as the hash of the data provided by the issuer and whether the issuer is a trustworthy organization. Once verification is completed, the necessary services are provided to the patient. Although it may seem a bit complicated, all of these processes are handled quickly by automated software, so patients will feel like it is a normal, simple authentication process.

In some cases, you can select and share only the data you want rather than sharing all of the data. The purpose can be achieved without even sharing data that may reveal personal information to the other party. An example would be a situation where you need to prove that you are the legal representative (guardian) of your child. First, information about your child and your relationship with your child must be stored in your data wallet. Hospital staff will ask you to scan a QR code to verify that you are your child's guardian. When you scan and approve the QR code, the system only checks whether you are registered as the patient's guardian without revealing personal information such as name, date of birth, gender, and address, and only reports the result as correct or incorrect. This method is called zero-knowledge proof. The purpose can be achieved because hospital staff only need to verify the actual guardian, not personal information.

Figure 14 shows an example of an additional service utilizing data in conjunction with a data wallet according to various embodiments of the present invention.

Consent (Signature) Management

There is no major problem with the existing method of consent itself. It has already been explained that the user can press the consent button in the authentication, login, and data management above, and this is similar to the existing method.

The difference is that in Data Wallet, you can check the details of your consent at once, and if you no longer want to give permission to the other party, you can withdraw it at any time. The existing method is cumbersome, requiring you to visit the relevant service one by one, withdrawing consent is generally not easy, and even requires filling out separate documents. In contrast, data wallets provide users with maximum self-determination rights over information even after consent.

Additionally, any data the user agrees to share can be signed with the user's encryption key, like a watermark. Using this, if the data held by a specific institution does not have a watermark, the institution must prove how it legally possessed the data. This allows information subjects’ data to be distributed in a more secure manner.

Meanwhile, the essential problem with the existing method is how to secure consent by forcing the user to display a statement saying that he or she has read and agree to the terms and conditions and to press the agree button as proof of this. This is closer to protecting companies providing services rather than information subjects. Because the terms of service and privacy policies are so long and complex, it is realistically difficult for users to read them all closely and review whether there are unreasonable provisions. This is also the reason why insufficient consent inevitably occurs.

To solve this problem, various embodiments of the present invention introduce standardized licenses for policies that sufficiently protect information subjects while ensuring reasonable use. If multiple services have the same information protection policy and you can trust that all the contents are the same even without reading it in detail, users will only need to read it properly once even if they use multiple services. From then on, as long as you confirm that you are using the same information protection policy license, you can simply click the agree button or set it to automatically agree if you wish. This will help in all aspects, including user convenience, user protection, and corporate consent securing rate.

If the policy contains provisions that do not exist in the standard or have not previously been agreed upon by the user, it can be separated into terms and conditions that require separate consent. In this case, the user only needs to check the changed or new content, so they can decide whether to agree or not with more confidence. These licenses can be managed in a decentralized governance framework to ensure trustworthiness.

management

Healthcare data must be collected and utilized on a global basis to reach its full potential. Data collection and use may be accomplished by providing the information subject with additional services created using the information, but in cases where there are no immediate services to provide, it may be more common and efficient to provide appropriate compensation. In that respect, it is necessary to support assets that allow data to be transmitted quickly and inexpensively on a global basis through the Internet, and to exchange and store them through a data wallet.

The most suitable assets for this would be Bitcoin and stablecoins linked to the dollar. In particular, thanks to the advancement of the Lightning network, money in the tens of dollars can be transferred anywhere in the world at the same speed as a credit card payment, with a fee of less than 0.0x dollars. Additionally, with the advancement of technologies such as Taproot and Taro, stablecoin transfers will become possible through the Bitcoin network.

If a data wallet according to various embodiments of the present invention is used, compensation on a global basis is possible through data collection and use in the form of assets preferred by users or companies. Since the data wallet according to various embodiments of the present invention will be implemented to be compatible with the BIP-39 standard, other altcoins such as HPO tokens and Ethereum can also be supported if necessary.

Backup and Restore

Since a data wallet stores valuable personal assets and data, it is also important to safely back up and restore them. Users can basically back up the mnemonic code displayed during the data wallet creation process by BIP-39 by recording it in a safe place. However, this method is somewhat unfamiliar, and in most cases, it can be burdensome because the individual must take full responsibility. To this end, we plan to encrypt the mnemonic code with an additional password set by the user and store it in a commonly used personal cloud storage such as iCloud or Google Drive.

This method is generally unsuitable for data wallets that store large amounts of assets, but it can be an appropriate trade-off because it can eliminate the risk of losing the mnemonic code itself for most users of data wallets according to various embodiments of the present invention. . Of course, users can choose a more secure method without storing it in personal cloud storage. As explained earlier, since it will be developed in compliance with Bitcoin wallet-related standards, methods to increase the security of Bitcoin wallets, such as adding a multi-sig wallet and passphrase, can be implemented in almost the same way.

Applications of data wallet according to various embodiments of the present invention

A data wallet application, which is a directory that can provide additional services using data or search for services that compensate for data, may be provided in conjunction with the data wallet according to various embodiments of the present invention. You can increase the utilization of your data wallet by looking in advance at what data each service requests and what services and rewards it provides.

Figure 15 shows an example of a function for issuing actual patient data to a data wallet according to various embodiments of the present invention.

alarm

A notification function is necessary for users to confirm essential notices or consent requests in a timely manner. To effectively capture the user's attention, we will utilize the device's system notification feature only when consent and signature are required.

agent, guardian

In general, the wallet owner and the data subject are the same, but many patients may find it difficult to manage their data wallet on their own for reasons such as health or lack of understanding of technology. In these cases, the ability to designate a proxy at the data wallet level can be provided so that others can make decisions about consent and data sharing on behalf of the patient. At this time, a wallet user with agent qualifications can have the authority to store and control the information subject's data in the wallet on his or her behalf.

These agents can be individuals, such as guardians, as well as organizations. Additionally, this function can be expanded to allow the guardian to take over the patient's assets and data when the patient dies. Although additional confirmation is needed to determine whether this method is permitted under each country's laws, identity verification for agents and guardians can be implemented electronically through the verifiable credentials (VC) described above.

Log

All activities that occur using the data wallet can be encrypted and stored on the user's device for later auditing. Log information stored in this way can be used to closely analyze responsibility and identify the cause when an accident or error occurs.

Data issuance and use

Data issuance

Data issuing organizations can issue data in the form of verifiable credentials (VC). To do this, you need to create a wallet and DID. Additionally, the data issuance SDK must be integrated into the institution's internal system. Then, preparations for basic data issuance are completed.

Data can be issued for each case upon request from the information subject, or can be issued in bulk by entering the DID of the issuance target on the internal administrator page. In both methods, the data model must be converted so that the institution's internal data can be issued in VC format. Currently, VCs can be issued using two syntactic representations, JSON-LD and JWT, without converting all data to these data models and encrypting data files with the data subject's public key in a secure data storage (SDS), such as the aforementioned IPFS. There is also a way to include the hash value generated after uploading the hash value in the VC. At this time, the data included in the VC can be expressed in a form compatible with various services by using the schema defined in schema.org. Since healthcare-related schemas such as Health and Medical have already been defined, frequently used VC templates are created based on this. The compatibility of data exchanged through data wallets can be increased by providing and encouraging reuse. Additionally, a method of defining a VC schema frequently used in various embodiments of the present invention and managing it through a governance framework can also be adopted.

FIG. 16 illustrates an example of a process for generating medical data from selected patients for reliable research by medical researchers according to various embodiments of the present invention.

The above-described functions are first applied to Raredata, a clinical research data management program, and can be provided as a function to issue actual patient data as a data wallet along with the data issuance SDK. The SDK can be freely integrated into other commercial/non-commercial products without a separate contract.

Raredata, a clinical research data management program, can supply reliable, high-quality data to the ecosystem according to various embodiments of the present invention. Raredata's main customers, medical researchers, generate a variety of high-quality data from selected patients for reliable research. In particular, in most clinical studies, researchers from multiple institutions collaborate to construct data to ensure representativeness of the data. In this process, the types, terms, and collection methods of data are inevitably structured systematically. Additionally, because reproducibility of research results is important, incentives for intentional manipulation of data are minimized. Through this mechanism, not only the data distribution process through VC but also the reliability of the source data can be secured.

Another important information included in VC is the commission rate that will be distributed to the issuing organization when the issued data is traded. Until now, there was practically no way for data issuing organizations to claim their share of data exported outside the organization. If VC is used, all data can be distributed only after the patient's decision, and the amount for data traded for a fee with the patient's consent is automatically distributed to the patient and the issuing organization. Through this, data issuing organizations can secure incentives arising from data utilization in addition to data issuance fees. This mechanism motivates issuing organizations to prepare and issue more reliable and usable data.

Figure 17 shows an example of data utilization according to various embodiments of the present invention.

Use your data

Organizations that develop artificial intelligence healthcare solutions, provide data-based healthcare services using already developed solutions, or have the purpose of screening suitable participants for clinical trials can use various embodiments of the present invention. Once consent is reached, reliable data can be used. To do this, first prepare a data wallet and DID to be used by the data utilization agency. And the data utilization SDK must be integrated into the institution's internal services. Then, the data is ready for use.

In order to utilize data, it is necessary to link the DID of the information subject and the DID of the utilizing organization. This is generally done by asking the information subject to scan a QR code for purposes such as login, authentication, and connection, and the information subject agrees after scanning. Utilizing organizations do not need to request all information at once. In the initial stage, data can be secured by requesting only the information necessary for basic service use and separately requesting information that requires a higher level of user consent. Using this method, you can secure appropriate data for each funnel through which user conversion occurs. The information that must be conveyed to the data subject when securing consent includes information on the utilizing agency, the content of the requested authority, and what data is to be used and under what conditions. This corresponds to the stage of presenting and receiving consent to legal notices for data collection and use, such as the existing terms of use and personal information protection policy. The difference is that utilizing organizations can adopt standardized terms and conditions certified by a governance framework. The advantage of this method, as explained in the consent (signature) management of the data wallet, is that there is no need for the data subject to make efforts to check the legal notice in detail every time, and from the institution's point of view, it is necessary to obtain a license with appropriate compliance requirements for each country and situation. All you have to do is adopt it. This will significantly reduce the cost and time for legal review and make it easier to secure sufficient consent.

Data utilization organizations can use Hippocrat DAO's standardized protocols and licenses through the CompliantData SDK.

Figure 18 shows an example of increased consent for data sharing due to increased compensation for data and reduced risk of personal information infringement according to various embodiments of the present invention.

The above-mentioned functions were first applied to Rarenote, a service for rare disease patients, and together with the data utilization SDK, actual patients can use health management and community services through data stored in their data wallet. The SDK can be freely integrated into other commercial/non-commercial products without a separate contract.

Rarenote can provide a place where patients can utilize the data wallet in the ecosystem according to various embodiments of the present invention. Rarenote provides reliable customized information, health management solutions, and community experiences based on data obtained with sufficient consent to patients with diseases that have difficulty accessing treatments, such as rare diseases and incurable cancers. Furthermore, if the patient-derived health data generated during the service use process and the clinical data submitted through the wallet are integrated and processed into a form that can be used by other data demand organizations such as pharmaceutical companies, it will be possible to sell data with high added value. You can. This process is based on the patient's consent, and the generated revenue becomes a source of compensation distributed to patients and data issuing organizations, enabling sustainable data compensation and utilization.

To implement this scenario, conditions for data use and compensation are included in the patient's consent. In particular, depending on the level of personal information disclosure, data can be divided into protected medical information, non-identified medical information, limited data sets or identified medical information, anonymous medical information, and pseudonymous medical information. In general, the higher the level of personal information and the more information requested, the higher the compensation amount, but the likelihood that the patient will refuse to protect personal information also increases. Accordingly, data-using organizations will try to secure only the necessary data that can persuade patients. In addition, since a lot of public resources are invested in the data creation process, it can be designed so that the more pseudonymous or anonymous the information is and the more it is used for scientific research purposes, the larger the proportion of compensation distributed for public purposes. These mechanisms can contribute to improving the quality of public health care services.

The greater the reward for data and the lower the risk of privacy infringement, the greater the likelihood of obtaining consent to share data.

Figure 19 shows an example of a governance protocol according to various embodiments of the present invention.

Governance and DAOs

COVID-19 has confirmed that human health requires cooperation on a global basis, not just one country or race. Accordingly, various embodiments of the present invention are oriented toward an open and decentralized cooperation mechanism that is not dependent on a specific country or organization. Accordingly, we plan to implement the Hippocrat protocol based on layer networks and protocols such as Bitcoin, Lightning, and Liquid, which are the most open and decentralized blockchains, and all software, including smart contracts, are developed with open standards and open source. .

Hereinafter, initial proposals for policies according to various embodiments of the present invention and the approach process in establishing such policies will be described. Specific governance protocols for each policy are codified and published in a verifiable form.

Figure 20 shows an example of a data collection and compensation system according to various embodiments of the present invention.

Governance Participation Eligibility

Participation in basic governance does not require any special qualifications. Anyone can freely express policy opinions and suggest improvements to open source code through the forum. The consensus method will be the rough consensus adopted by the Internet engineering task force (IETF). However, some authorities that require clear roles and responsibilities, such as adopting standard policies, reviewing institutional certification, selecting holders of authority to modify protocol source code, and selecting holders of DAO finance and related wallet management, are assigned to single or multiple members elected by agreement among DAO members. may be granted. Additionally, some rights depend on whether the wallet owner has a VC that can prove they are a specific stakeholder, such as a patient with a specific disease or a representative of a medical institution. Accordingly, we ensure that the opinions of specific stakeholders are given weight.

In order to prevent power from being concentrated and abused by a few, many members with distributed interests can have authority, and decisions are made in a way that sufficient agreement is reached among them. This authority can be proven by receiving VC for the authority from the DAO or existing authority holder using the party's DID. Typically, these permissions have an expiration date dictated by policy and will expire if not renewed.

DAO's role

Basically, the various embodiments of the present invention develop software and policies in the form of open source and voluntary open cooperation, but the main elements of the various embodiments of the present invention, such as data wallet and SDK, are developed and standard policies are drafted. In this case, it can be more efficient when there is an organization with systematically defined responsibilities and roles. To this end, some of the community can contribute by belonging to the Hippocrat DAO (Decentralized autonomous organization).

Hippocrat DAO aims for a decentralized structure and an autonomously operating organization. To this end, we implement as many things as possible to be operated by smart contracts, but not everything may be possible due to technical or legal limitations. In such cases, an organization and members operated by people based on a system with clear roles and responsibilities are needed. Therefore, if you have the expertise and experience required by the DAO, you can participate in governance by working for the DAO. DAO will be comprised of those who can help the growth of the ecosystem according to various embodiments of the present invention and will have a system free from specific individuals or institutions.

DAO Treasury Management

In the case of data traded with monetary compensation provided through the data utilization SDK, 10% of the transaction amount becomes the DAO's income as a protocol fee. The DAO grants elected officials the authority to manage the Treasury, where this income and the tokens received from the Hippocrat Foundation are stored, thereby managing the necessary income and expenses.

The reason why such authority is necessary is because although there are cases where it is automatically done by smart contracts, such as the distribution of incentives that occur in data transactions, there are also contracts and transactions that cannot be expressed through smart contracts. And since smart contracts are initially designed by people, they also participate in the process. This is similar to the decision-making process for cost execution in traditional organizational systems. Instead, all decisions are transparently recorded and made public.

Meanwhile, if the type of data being traded has a low possibility of personal identification and is of high public interest, additional deductions are made for public health care resources separately from the protocol fee. The amount accumulated through this public health care resource deduction is managed separately from the DAO's operating budget and can only be used for the purpose of donating to public health care institutions in each country. This starts at a minimum of 10% and can be levied up to 30% as the possibility of personal identification is low and the public interest is high. The financial resources accumulated in this way will enable smooth cooperation with public health care institutions in each country.

Figure 21 shows an example of a compensation system based on data collection and utilization according to various embodiments of the present invention.

Standard legal notice management

DAO provides legal notices such as terms of use and privacy protection policies that data users can use when presenting to data subjects and seeking consent, standardized by country and data use purpose. If the data user selects the appropriate items from these standardized legal notices through the Data Usage SDK, the data subject can confirm them when sharing data through the data wallet. If data subjects of different nationalities are targeted, legal notices appropriate to the nationality of each data subject are displayed.

The DAO is responsible for creating legal notices for each country and situation to help data users utilize data well while protecting data subjects. The legal notice written in this way is stored in a decentralized storage, and the hash value of each file is registered in the standard terms and conditions registry and certified as the standard for various embodiments of the present invention. If the legal notice adopted by the data user is registered in the standard terms and conditions registry, the data subject can confirm that it is authenticated. Additionally, items with the same hash value can be set to automatically agree without further action in the future. Although not all terms and conditions are agreed upon by default, this method allows users to understand the content only once and does not have to review the same content repeatedly thereafter. Data users will also be able to efficiently secure sufficient consent. This is the benefit of standardization.

If changes are needed to the legal notice, this can be done through consensus among governance participants with the authority to manage data standard terms and conditions. This can only be reflected in the actual registry if the minutes are made public, such as in a forum, and changes are sufficiently agreed upon. In addition, the distribution rate of public resources according to the public interest of data use and personal identification is also determined by the above procedure.

Data issuance authentication management

When a data-using agency utilizes some data, one may wonder whether the data was actually issued by a valid agency. Therefore, the data issuing agency's data wallet must have essential information about the issuing agency recorded in VC format. For example, in the case of a hospital, it includes the hospital name, address, registration number, issuing person's name, email address, contact information, etc. Additionally, the commission rate to be distributed to the data issuer when data is traded must also be included. This information can be viewed publicly without a separate request or information sharing process.

However, from a third party's perspective, this information cannot be trusted as is. Therefore, various embodiments of the present invention operate a registry that can query the authentication process and certification authority for the issuing authority through DAO. This information is verified through an institutional certification review, and when verification is completed, the DID address of the institution is added to the registry of the certified institution. The data utilization SDK reports the value ‘verified’ if the issuing authority of the VC being verified is included in this registry. Through this, the utilizing institution can trust and utilize the validity of the institution's information without a separate verification process.

Data wallet application management according to various embodiments of the present invention

The data wallet according to various embodiments of the present invention provides Hippocrat Apps, a directory where users can explore data wallet applications using their own data. These applications can be of various types, from services such as step counting to digital therapeutics. Here, users can review the data utilization services, data compensation, and data utilization conditions provided by each application. Through this, each application has the opportunity to inform and introduce its services to information subjects.

To be displayed in Hippocrat Apps, you must apply for publication through DAO, and governance participants with management authority can decide what is displayed in Hippocrat Apps after review. The posting list and policies are managed as open source through Github, etc., and everything from application to screening and exposure decision is transparently recorded. In addition, lists that are not reviewed by the DAO can be posted without separate review if information is posted in accordance with the standards.

management

The official software program source code of the protocol, such as data wallet, SDK, and website according to various embodiments of the present invention, is mainly managed by the DAO. It is basically developed with open standards and open source, but if it relies solely on contributions from third parties, development efficiency may be reduced or sustainable development may not be achieved. Source code management rights are granted to multiple members, and some rights are managed only when an agreement is reached between members.

In addition to the areas mentioned above, any agenda that is developed based on consensus among various stakeholders and requires notification can be discussed and decided by governance.

incentive model

Stakeholders related to various embodiments of the present invention are largely divided into users and governance participants. Governance participants, including DAOs, will design good protocols and receive incentives for the protocols to operate and develop well, and users will expect incentives to solve their problems or gain economic benefits by using the protocols. There are times when one person plays two roles, but in some situations the roles are clearly distinct. Therefore, incentive models should be separated by role to avoid confusion and be designed to better match the motivation of each role.

Various embodiments of the present invention seek to comply with the regulations of major countries for a reliable and sustainable token economy, and establish consensus with the community based on the final legislation for digital assets currently in progress in major countries such as the United States, Europe, and Korea. The incentive model can be determined through .

Active governance participants will propose agenda items and try to persuade other governance participants so that their claims and opinions on specific policies or issues are reflected at the protocol level. However, it may be difficult to expect all participants to have the expertise and capacity to participate at this level. In these cases, you can express your support by voting for arguments and agendas that best represent your interests.

Users need currency to efficiently exchange the value provided by each other on the protocol. To this end, various embodiments of the present invention use not only HPO, which is a protocol native token, but also Bitcoin and dollar-linked Stablecoin, which are most widely adopted in each of the global decentralized ecosystem and fiat currency-based ecosystem, as currencies for value exchange between users. use.

Initial proposals for user-specific incentive policies of various embodiments of the present invention are as follows. This may be changed by new incentive policy proposals and votes.

1. Data subject

The information subject has the right to confirm and decide on the use and transaction details of data. You can enjoy services using your own data as incentives, and you can also receive economic compensation offered by data users as incentives in return for sharing data. Then, the remainder, excluding the protocol fee and deduction for public health care funding purposes, is shared between the information subject and the data issuer according to the distribution ratio. However, under any condition, the principle is that the information subject receives the largest share, and at least 40% to a maximum of 90% of the total compensation goes to the information subject.

2. Data issuer

The data issuer provides the costs and expertise necessary to generate data, and has the authority to set the compensation distribution rate between the information subject and the data issuer when issuing data. If economic benefits arise from data transactions determined by the data subject, the data issuer will receive compensation based on this distribution rate as an incentive. However, the data issuer may set the distribution rate to no more than half of the data subject's share. Within this upper limit, the data issuer can voluntarily determine the distribution rate, but if the data subject determines that the distribution rate of another data issuing organization is more reasonable, there is an incentive to change the issuing organization. In other words, from the perspective of issuing organizations such as hospitals, patients may leave to other hospitals. However, the more data can only be issued by a specific institution, the more likely it is that the distribution rate will be set so that the issuing institution's share is larger. Various embodiments of the present invention allow an appropriate distribution rate to be determined by this market mechanism.

3. Data user

Data users secure consent to data collection and use by offering attractive services or economic rewards to data subjects. At this time, compliance costs can be minimized by using the standardized legal notice provided by the protocol, and data collection and use can be made efficient by utilizing the SDK. The higher the public interest of the data to be collected and used in the legal notice, and the less personally identifiable, the greater the share that will be allocated as public resources. Public resources are managed separately according to the nationality of the information subject and donated to each country's government or public health care institutions. Through this, global pharmaceutical companies and healthcare service providers can expect appropriate cooperation from public institutions when using public interest data such as medical research in each country.

HPO Token

HPO tokens are used after purchase by data consumers in the ecosystem according to various embodiments of the present invention to pay compensation to information subjects in return for data sharing.

Benefit

Until now, individuals have had no way to have complete sovereignty over their own information. In particular, in the past 10 years, as large Internet platforms have grown, the concentration of personal information on them has intensified, and side effects such as large-scale information leaks and added value monopolies have also intensified. My Data and the self-sovereign identity movement, which began as a solution to this problem, will contribute to returning sovereignty to the data subject.

In particular, these problems and importance are greater in the medical field. It is important for information subjects to secure sovereignty not only for the purpose of protecting individuals, but also in terms of industrial development and practical benefits that individuals can enjoy. Focusing on this, it is also necessary to ensure that the motivations of stakeholders surrounding information subjects are met and that effective cooperation is achieved. Various embodiments of the present invention will realize this, and the expected effects are summarized as follows.

Benefit Conventional method This invention (Hippocrat) Data Management and Integration institution-centered Data subject-centered Obtaining and managing patient consent difficulty facility incentive exchange difficulty facility Data forgery/falsification possible impossible Medical information export format Non-electronic (paper printing, CD, etc.) Electronic (VC) Duplicate data collection Frequent minimization

Examples that each stakeholder can use through various embodiments of the present invention are as follows.

patient, data subject

Medical information authentication

When you scan the registration and reception QR code provided at the hospital with the data wallet application, you can easily and safely authenticate yourself with the stored legal identification information, receive a patient registration card, and store it in the data wallet. The patient registration card records information such as diagnosis, test results, and prescribed medications, so that related information can be submitted when registering at the hospital or applying for insurance benefits. Additionally, you can present the vaccine pass stored in the application when checking whether you have been vaccinated at the airport or certain public facilities. Even in situations where medical information submission and authentication are required, only necessary medical information can be easily conveyed without exposing unnecessary personal information.

Data Monetization

Pharmaceutical companies and healthcare service providers are willing to pay for data collection to develop value-added new drugs and services. In particular, there is an increasing number of cases where not only clinical data generated from hospitals, but also patient data generated from services used through personal devices such as social networks, shopping, fitness, and mobility are being used for healthcare purposes. Therefore, the frequency and amount of compensation received in return for allowing various organizations and companies to utilize their data will also increase. Even if data has already been shared, it can be equally shared with other audiences, enabling continuous monetization. Patients can approve data transactions through data wallets according to various embodiments of the present invention, and collect and manage compensation received in return in the data wallet.

Personalized health care

Patients are willing to pay for health care services that can improve their health and quality of life. By allowing patients to provide services that utilize healthcare data stored in their own data wallets, patients can enjoy customized healthcare services.

Pharmaceutical companies and healthcare service providers

Secure sufficient consent-based data

In the case of data for which sufficient consent has been obtained from patients, data damage is minimized through intensive de-identification processing, and new discoveries are possible through combination with other datasets. In addition, it enables more innovative and challenging attempts by enabling the use of de-identified data for a wider range of purposes and commercialization than the purposes guaranteed by law. In addition, because the consent received directly from the patient is shared as data, the cost spent on companies acting as intermediaries can be reduced or the possibility of securing data can be increased by offering more attractive compensation to the patient.

Screening of clinical trial participants

By using data already issued in the patient's data wallet, the screening process for patients suitable for clinical trials progresses much more efficiently. For example, when a patient interested in a clinical trial scans the QR code attached to the clinical trial recruitment notice, their availability for participation is immediately displayed based on the data stored in the data wallet, and they can convey their intention to participate. In particular, clinical trial selection and exclusion conditions are often made confidential, and by using zero-knowledge proof, only suitability can be checked while these conditions and the patient's personal information are kept private.

Development of customized healthcare services

Healthcare service development organizations can secure data for developing personalized services on a global basis through a data wallet that stores various healthcare data, including patient-centered integrated clinical data. Even after the development stage and the commercialization stage, you can immediately provide customized services by simply connecting your wallet without complicated membership registration, increasing the purchase conversion rate of users, and operating a global business while minimizing compliance issues with standardized legal notices for each country. .

Medical institutions such as hospitals

Streamlined patient information issuance

We can effectively respond to measures taken by government agencies in major countries, such as the United States, to legislate to allow data stored in medical institutions to be exported to the outside world in electronic form. By using Raredata, which is equipped with a data wallet and data issuance SDK according to various embodiments of the present invention, collected data can be issued in electronic form with just a few clicks. This allows compliance with regulations without additional costs and increases patient satisfaction through a system that is friendly to patient data sovereignty.

Data Monetization

When data is issued to a patient's data wallet, the medical institution's digital signature is recorded so that the distribution path of the issued data can be tracked even after it is exported, and if it is shared with a third party for a fee through the patient, part of it is recorded. Automatically distributed to medical institutions. Through this, costs for professional equipment and manpower invested for data issuance and management can be recovered, and additional profits can be expected through active data utilization.

Activation of clinical research

In the case of clinical research conducted by medical institutions themselves without sponsors such as pharmaceutical companies, it is difficult to activate due to budget limitations. Additionally, it costs a considerable amount of time and money to obtain patient consent and collect data to conduct clinical research. If there is data from another clinical study in the patient's data wallet, it can be used with the patient's consent, saving the time, effort, and cost of the patient and the research team in collecting duplicate data. More diverse research can be promoted even without sponsors.

public health care institution

Establishing and utilizing public data

Research conducted for the public interest by public health care organizations, such as All of US, can also significantly save time and cost by collecting data directly from information subjects, allowing limited public budgets to be used more efficiently. The data collected in this way is processed into a dataset for public purposes, which in turn helps promote the development of public health care.

Secure public health care financing

When data with low personal identification is traded for public interest purposes, it is accumulated as a resource to be donated to public health and medical institutions of the nationality of the data subject. Through this, we will realize a balance between the rights of information subjects and the public nature of health care data, and maintain a positive cooperative relationship between Hippocrat and each national organization.

When implementing embodiments of the present invention using hardware, application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), and programmable logic devices (PLDs) configured to perform the present invention. , FPGAs (field programmable gate arrays), etc. may be provided in the processor 505 of the present invention.

Meanwhile, the above-described method can be written as a program that can be executed on a computer, and can be implemented in a general-purpose digital computer that operates the program using a computer-readable medium. Additionally, the data structure used in the above-described method can be recorded on a computer-readable storage medium through various means. Program storage devices, which may be used to describe a storage device containing executable computer code for performing various methods of the present invention, should not be understood to include transient objects such as carrier waves or signals. do. The computer-readable storage media includes storage media such as magnetic storage media (eg, ROM, floppy disk, hard disk, etc.) and optical readable media (eg, CD-ROM, DVD, etc.).

The embodiments described above combine the components and features of the present invention in a predetermined form. Each component or feature should be considered optional unless explicitly stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. Additionally, it is possible to configure an embodiment of the present invention by combining some components and/or features. The order of operations described in embodiments of the invention may be changed. Some features or features of one embodiment may be included in another embodiment or may be replaced with corresponding features or features of another embodiment. It is obvious that claims that do not have an explicit reference relationship in the patent claims can be combined to form an embodiment or included as a new claim through amendment after filing.

It will be clear to those skilled in the art that the present invention can be embodied in other forms without departing from the technical spirit and essential features of the present invention. Accordingly, the above embodiments should be considered in all respects as illustrative rather than restrictive. The scope of rights of the present invention should be determined by reasonable interpretation of the appended claims and all possible changes within the equivalent scope of the present invention.

Claims (10)

A method of operating a server in a communication system, wherein the server includes a transceiver, a memory, and a processor,
Exchanging information of a first cryptocurrency wallet of the patient terminal and the server and information of a second cryptocurrency wallet of the patient terminal by the transceiver;
Transmitting, by the transceiver, one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network;
Receiving, by the transceiver, a request message for the transaction information related to the two logics in the first cryptocurrency wallet from a hospital terminal - Decentralized Identifier (DID) of the patient terminal is the first password Containing a first address of a currency wallet and a second address of the second cryptocurrency wallet;
Transmitting, by the transceiver, a response message containing the transaction information of the first cryptocurrency wallet related to the two logics to the hospital terminal,
The DID based on the common presence of one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN to the first address of the first cryptocurrency wallet and the second address of the second cryptocurrency wallet. The validity of is proven,
The OP_RETURN is information that when creating a transaction, the signature data of the server is emptied without inserting the signature data in a predetermined location, or other data is inserted instead of the signature data,
method.
According to claim 1,
The OP_RETURN includes the DID of the patient terminal generated by the server instead of the signature data,
method.
According to claim 1,
The patient terminal and the hospital terminal have decentralized identity information (Decentralized Identifier, DID) managed by the server,
method.
According to claim 1,
Regarding the security of medical data transmission between the patient terminal and the hospital terminal,
Data encryption and decryption are performed by the processor without sharing the private key between the patient terminal and the hospital terminal using Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Diffie-Hellman (ECDH) to generate a shared key. ,
AES-GCM (Advanced Encryption Standard Galois/Counter Mode) for encrypting the medical data before transmission of the medical data between the patient terminal and the hospital terminal to ensure data integrity and confidentiality is performed by the processor,
method.
A method of operating a patient terminal in a communication system, wherein the patient terminal includes a transceiver, a memory, and a processor,
Exchanging information between a server and a first cryptocurrency wallet of the server and information of a second cryptocurrency wallet of the patient terminal by the transceiver;
Transmitting, by the transceiver, one transaction information related to two logics for receiving a set amount of cryptocurrency and OP_RETURN from the first cryptocurrency wallet to the second cryptocurrency wallet to the blockchain network;
Generating, by the processor, a key pair of a random private key and a random public key based on the Elliptic Curve Integrated Encryption Scheme (ECIES) method for each communication instance;
Encrypting medical data of the patient terminal by the processor using an Elliptic Curve Diffie-Hellman (ECDH) shared key calculated from the random private key of the patient terminal and the public key of the hospital terminal;
Transmitting the encrypted medical data together with the random public key of the patient terminal to the hospital terminal by the transceiver based on the decentralized identifier (DID) of the patient terminal,
The DID includes a first address of the first cryptocurrency wallet and a second address of the second cryptocurrency wallet,
The DID based on the common presence of one transaction information related to two logics for transmitting a set amount of cryptocurrency and OP_RETURN to the first address of the first cryptocurrency wallet and the second address of the second cryptocurrency wallet. The validity of is proven,
The OP_RETURN is information that when creating a transaction, the signature data of the server is emptied without inserting the signature data in a predetermined location, or other data is inserted instead of the signature data,
method.
According to clause 5,
The OP_RETURN includes the DID of the patient terminal generated by the server instead of the signature data,
method.
According to clause 5,
The patient terminal and the hospital terminal have decentralized identity information (Decentralized Identifier, DID) managed by the server,
method.
According to clause 5,
Regarding the security of transmission of the medical data between the patient terminal and the hospital terminal,
Data encryption and decryption are performed without sharing the private key between the patient terminal and the hospital terminal using Elliptic Curve Integrated Encryption Scheme (ECIES) and Elliptic Curve Diffie-Hellman (ECDH) to generate a shared key,
AES-GCM (Advanced Encryption Standard Galois/Counter Mode) is performed to encrypt the medical data before transmission of the medical data between the patient terminal and the hospital terminal to ensure data integrity and confidentiality.
method.
In a server in a communication system,
transceiver;
Memory; and
Includes a processor,
The processor is configured to perform the method of any one of claims 1 to 4,
server.
In the patient terminal in the communication system,
transceiver;
Memory; and
Includes a processor,
The processor is configured to perform the method of any one of claims 5 to 8,
Patient terminal.

Images