Method and system for sharing medical data

Abstract

The embodiment of the specification provides a medical data sharing method and system, the method is applied to a service provider and includes the following steps: obtaining a data request of a user about target medical data and a user public key; performing user verification of the user, which includes the following steps: interacting with a permission chain commonly owned by a plurality of data parties to verify whether the user has relevant permissions corresponding to the target medical data based on the user public key through the permission chain, and the permission chain stores user permission information; when the user verification is passed, accessing a private data chain of a data party, and performing an operation related to the data request on the target medical data on the private data chain, and the private data chain stores private medical data of the data party.

Description

TECHNICAL FIELD

[0001] The present specification relates to the field of medicine, and in particular to a medical data sharing method and system. BACKGROUND

[0002] With the construction and development of the medical system, data sharing and exchange between various medical institutions (for example, hospitals) are also becoming more and more common. At present, medical institutions usually use traditional databases as medical data management systems, resulting in serious data centralization, difficulty in tracking data flow and historical operation records, high risk of medical data leakage, and great harm. Based on the protection of data, medical institutions do not allow external access to data, making it impossible to connect data, and the existing data management method is difficult to ensure the privacy and security of data while sharing data. At the same time, the non-uniformity of data standards between hospitals, as well as the differences in data, processes and supporting manufacturers between hospitals and many other factors, result in poor interoperability between different medical systems, further exacerbating the difficulty of cross-hospital data sharing. The decentralization of patient medical data makes it difficult to share data across hospitals and between hospitals, resulting in incomplete treatment information, and medical teams being unable to fully understand the patient's previous medical history, treatment plan and corresponding treatment results, etc. This results in the inability to develop the most optimal personalized treatment plan for patients, hindering the improvement of patient treatment levels.

[0003] Therefore, it is desirable to provide a medical data sharing method and system. SUMMARY

[0004] One of the embodiments of the present specification provides a medical data sharing method applied to a service provider. The method comprises: obtaining a data request of a user about target medical data and a user public key; performing user verification of the user, which comprises: interacting with a permission chain commonly owned by a plurality of data parties to verify whether the user has relevant permissions corresponding to the target medical data based on the user public key through the permission chain, wherein user permission information is stored on the permission chain; when the user verification is passed, accessing a private data chain of a data party, and performing an operation related to the data request on the target medical data on the private data chain, wherein the private data chain stores private medical data of the data party.

[0005] In some embodiments, the relevant permissions can include at least one of the following: patient-related permissions, data party-related permissions, department-related permissions, and data operation permissions.

[0006] In some embodiments, the data operation permissions can include at least one of the following: data reading permissions, data writing permissions, and data modification permissions.

[0007] In some embodiments, the user can be verified to have the relevant permission corresponding to the target medical data based on the user public key and the relevant information of the target medical data through the permission verification smart contract.

[0008] In some embodiments, the user identity of the user can be verified to be consistent with the user public key through zero-knowledge proof.

[0009] In some embodiments, the user identity of the user can be verified to be consistent with the user public key through zero-knowledge proof in the following manner: a random number is generated, and the random number is encrypted based on the user public key to obtain first ciphertext; the first decryption result obtained by the user using a user private key to decrypt the first ciphertext is obtained; and in response to the random number being consistent with the first decryption result, it is determined that the user identity is consistent with the user public key.

[0010] In some embodiments, the user identity of the user can be verified to be consistent with the user public key through zero-knowledge proof in the following manner: second ciphertext obtained by the user using a user private key to encrypt the user public key is obtained; the second ciphertext is decrypted using the user public key to obtain a second decryption result; and in response to the user public key being consistent with the second decryption result, it is determined that the user identity is consistent with the user public key.

[0011] In some embodiments, the data interaction of the private data chain can be performed through network encryption transmission.

[0012] In some embodiments, the private medical data can include anonymized medical data, which can be obtained by the following method: when the private medical data is packaged and stored on the private data chain, a preset proportion of the private medical data is anonymized to obtain the anonymized medical data; and the anonymized medical data is stored on the private data chain.

[0013] One of the embodiments of the present specification provides a medical data sharing system applied to a service provider. The system comprises an acquisition module, a verification module and an access module; the acquisition module is used to acquire a data request of a user about target medical data and a user public key; the verification module is used to perform user verification of the user, which comprises: interacting with a permission chain shared by a plurality of data parties to verify whether the user has the relevant permission corresponding to the target medical data through the permission chain based on the user public key, the user permission information being stored on the permission chain; and the access module is used to access a private data chain of a data party and perform an operation related to the data request on the target medical data on the private data chain when the user verification is passed, the private data chain storing private medical data of the data party.

[0014] One of the embodiments of the present specification provides another medical data sharing method, applied to a data party, the data party has a private data chain private to the data party, and the private data chain stores private medical data of the data party. The method comprises: deploying an incentive mechanism on the private data chain, the incentive mechanism comprising: when a first preset number of private medical data is packaged and stored on the private data chain, a second preset number of data access right non-fungible tokens (NFTs) are automatically generated on the private data chain, and the data access right non-fungible tokens are used for the data party to access anonymized medical data on a private data chain of another data party through holding of the data access right non-fungible tokens.

[0015] In some embodiments, the data access right non-fungible token of the data party can be signed based on a private key of the data party to obtain a signed data access right non-fungible token. The data party can access the anonymized medical data on the private data chain of the other data party by sending the signed data access right non-fungible token and an anonymized data access request to the other data party or a service provider, so that the other data party or the service provider performs data access right verification based on a public key of the data party; when the data access right verification is passed, the other data party or the service provider allows the data party to access the anonymized medical data of the other data party.

[0016] One of the embodiments of the present specification provides another medical data sharing system, applied to a data party, the data party has a private data chain private to the data party, and the private data chain stores private medical data of the data party. The system comprises a first incentive module; the first incentive module is used for deploying an incentive mechanism on the private data chain, the incentive mechanism comprising: when a first preset number of private medical data is packaged and stored on the private data chain, a second preset number of data access right non-fungible tokens are automatically generated on the private data chain, and the data access right non-fungible tokens are used for the data party to access anonymized medical data on a private data chain of another data party through holding of the data access right non-fungible tokens.

[0017] One of the embodiments of the present specification provides another medical data sharing method, which is applied to a permission chain system shared by multiple data parties, and user permission information is stored on the permission chain. The method comprises: deploying an incentive mechanism on the permission chain, the incentive mechanism comprising: when a third preset number of user permission information on the permission chain is packaged and stored by a data party, a fourth preset number of data access permission non-homogeneous tokens are automatically generated on the permission chain and distributed to the data party, and the data access permission non-homogeneous tokens are used for the data party to access anonymized medical data on a private data chain of other data parties through the held data access permission non-homogeneous tokens.

[0018] One of the embodiments of the present specification provides another medical data sharing system, which is applied to a permission chain shared by multiple data parties, and user permission information is stored on the permission chain. The system comprises a second incentive module; the second incentive module is used for deploying an incentive mechanism on the permission chain, the incentive mechanism comprising: when a third preset number of user permission information on the permission chain is packaged and stored by a data party, a fourth preset number of data access permission non-homogeneous tokens are automatically generated on the permission chain and distributed to the data party, and the data access permission non-homogeneous tokens are used for the data party to access anonymized medical data on a private data chain of other data parties through the held data access permission non-homogeneous tokens.

[0019] One of the embodiments of the present specification provides a medical data sharing device, which comprises a processor, and the processor is used for executing the medical data sharing method.

[0020] One of the embodiments of the present specification provides a computer readable storage medium, which stores computer instructions, and when a computer reads the computer instructions in the storage medium, the computer executes the medical data sharing method.

[0021] In some embodiments of the present specification, medical data and permissions are stored through the decentralized principle of the blockchain, overcoming the problem that the loss of all data is caused by the damage of a traditional database, and the robustness of the data is significantly improved. Moreover, the centralized data flow and operation are difficult to track, and the security and traceability of the data are improved. Through zero-knowledge proof, the identity of the user is verified, and the user does not need to provide any personal privacy information (such as password or private key) to verify the identity, ensuring the security of the personal privacy of the access user. Through the private encrypted data chain and the public permission chain instead of the traditional public chain, multiple users can submit medical data access and operation requests from the application layer to the data layer, ensuring that hospital patients, medical staff, government regulatory agencies, scientific research personnel, public service agencies, and medical insurance agencies can access and operate the encrypted medical data in each medical institution according to their respective permissions in the permission chain, realizing cross-hospital sharing of data between hospitals. Through the deployment of attribute-based access control strategies in the blockchain contracts of the permission chain and the private data chain, it is ensured that only the access user who meets the access permission can operate the data in the cross-hospital sharing, so that the accuracy of cross-hospital data sharing is improved while the data access is fine-grained. Through automatic anonymization processing of a preset proportion of data during the packaging of data in the permission chain and the private data chain, anonymized data is generated, and the data party accesses the anonymized data by means of the data access permission non-fungible token (NFT) generated by the incentive mechanism on the blockchain, so that the patient's identity information can be shielded, and the data access party can only obtain the patient's health data, but cannot associate it with the patient's identity, thereby avoiding the leakage of the patient's identity information and health information, protecting the patient's personal privacy, and ensuring the demand for medical data in specific situations such as scientific research. BRIEF DESCRIPTION OF DRAWINGS

[0022] The present specification will be further illustrated in the form of exemplary embodiments, which will be described in detail with reference to the accompanying drawings. These embodiments are not limiting, and in these embodiments, the same numbers represent the same structures, wherein:

[0023] Figure 1 is a schematic diagram of an application scenario of a medical data sharing system according to some embodiments of the present specification;

[0024] Figure 2 is a schematic diagram of a medical data sharing system according to some embodiments of the present specification;

[0025] Figure 3 is an exemplary flowchart of a medical data sharing method according to some embodiments of the present specification;

[0026] Figure 4is a schematic diagram of a medical data sharing method according to some embodiments of the present specification;

[0027] Figure 5 is a schematic diagram of a medical data sharing system according to some embodiments of the present specification;

[0028] Figure 6 is an exemplary flowchart of a medical data sharing method according to some embodiments of the present specification;

[0029] Figure 7 is an exemplary flowchart of an interactive zero-knowledge proof method for confirming user identity according to some embodiments of the present specification;

[0030] Figure 8 is an exemplary flowchart of a non-interactive zero-knowledge proof method for confirming user identity according to some embodiments of the present specification;

[0031] Figure 9 is a network architecture schematic diagram of a medical data sharing system according to some embodiments of the present specification. DETAILED DESCRIPTION

[0032] In order to more clearly illustrate the technical solutions of the embodiments of the present specification, the following will briefly introduce the drawings needed to be used in the embodiment description. Obviously, the drawings in the following description are only some examples or embodiments of the present specification, and for those skilled in the art, the present specification can also be applied to other similar scenarios without creative labor. Unless it is clear from the language context or otherwise indicated, the same reference numbers in the drawings represent the same structure or operation.

[0033] It should be understood that the "system", "device", "unit" and / or "module" used herein is a method for distinguishing different components, elements, parts, sections or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0034] As shown in the specification and claims, unless the context clearly indicates otherwise, "one", "a", "an", and / or "the" do not refer to the singular, but can also include the plural. Generally speaking, the terms "comprise" and "include" only indicate the inclusion of the steps and elements explicitly identified, and these steps and elements do not constitute an exclusive list, and the method or device can also include other steps or elements.

[0035] Flowcharts are used in the specification to illustrate the operations according to embodiments of the specification in terms of a system performing actions. It will be understood that each operation does not have to be performed in the precise order illustrated or in sequential order, unless explicitly specified otherwise. Rather, various operations can be handled in parallel or in reverse order. Furthermore, other operations can be added or removed as appropriate. This description thus provides illustrative implementations as examples. Changes and modifications can be made to the implementations described without departing from the scope of the subject matter recited in the claims or the scope of the aspects disclosed.

[0036] Figure 1 FIG. 1 is a schematic diagram of an application scenario of a medical data sharing system according to some embodiments of the specification.

[0037] As shown in FIG. 1, in some embodiments, the system 100 can include a data party 110, a service provider 120, a permission chain system 130, a user terminal 140, and a network 150. Figure 1

[0038] The data party 110 refers to a provider of data. In some embodiments, the data party 110 can include a medical institution, such as a hospital, a medical examination institution, a clinic, etc., that can provide patient information and medical data generated during a patient’s visit, etc. In some embodiments, the data party 110 can include one or more, e.g., including 110-1, 110-2, …, 110-n, where n > 1. In some embodiments, the data party 110 can include one or more processing devices (e.g., a single-core processing device or a multi-core multi-core processing device), which can include a central processing unit (CPU), an application-specific integrated circuit (ASIC), an application-specific instruction processor (ASIP), a graphics processing unit (GPU), a physics processing unit (PPU), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic device (PLD), a controller, a microcontroller unit, a reduced instruction set computer (RISC), a microprocessor, etc., or any combination thereof. In some embodiments, the data party 110 can perform the medical data sharing method described in some embodiments of the specification through its processing device to complete one or more functions described in some embodiments of the specification. For example, the data party 110-1, 110-2, …, 110-n can perform user authentication, deploy an incentive mechanism, etc. on a public permission chain through its processing device. For another example, any of the data party 110-1, 110-2, …, 110-n can encrypt and package its private medical data, deploy an incentive mechanism, etc. on its private permission chain through its processing device.

[0039] ​The private data chain is a single data party's private encrypted blockchain, which is used to deploy a data chain contract and store the private data of the data party. The private blockchain (also referred to as a private chain or a private chain) is a blockchain that is open only to a single individual or entity. The private chain is centrally managed by an administrator, and the write permissions of each node in the system are allocated by the centralized administrator, which is highly centralized. The qualifications of the participating nodes of the private chain are strictly controlled, the number of nodes is limited and controllable, and privacy can be better protected. The connection between the nodes of the private chain is very convenient, and troubleshooting is easy, and manual intervention can be used. The transaction speed of the private chain is fast and the transaction cost is low. On the private chain, only a few high-power nodes with high recognition are needed to determine the transaction. In some embodiments, any one of the data parties 110-1, 110-2,..., 110-n can add, delete, or perform other operations on the attribute groups of the data and the data content on the private data chain of the data party according to a preset control policy. In some embodiments, the private data chain can provide the data party 110 (for example, the data party 110-1) that successfully packages the private data with access to the anonymized medical data within a certain period of time through its incentive mechanism. For more information about the private data chain, see Figure 5 The relevant description is not repeated here. In some embodiments, the private data chain can be deployed on the processing device of the data party 110. The data and information stored in the private data chain of the data party 110 can include private medical data of the data party 110 (for example, patient information and medical data generated during patient visits), a private data chain smart contract, and the like.

[0040] The permission chain is a blockchain that is public to multiple parties (for example, multiple data parties, service providers, and the like), which is used to deploy a record and store permission data. The public blockchain (also referred to as a public chain or a public chain) is a blockchain that is open to all people or entities. The participating nodes of the public chain can be any node, and all participating nodes can participate in reading and writing data, which is highly decentralized and theoretically cannot be tampered with. In some embodiments, the data party 110 can add, delete, or perform other operations on the attribute groups of the access visitors on the permission chain according to a preset control policy. In some embodiments, the permission chain can provide the data party 110 (for example, the data party 110-1) that successfully packages the permission data with access to the anonymized medical data within a certain period of time through its incentive mechanism. For more information about the permission chain, see Figure 5The related description is not repeated here. The permission chain can be implemented on the permission chain system 130, which is a public block chain system. The public block chain system can include a plurality of nodes (each node has its corresponding processing device) interconnected in communication, and each node can have a copy of the permission chain. In some embodiments, the plurality of nodes in the public block chain system can include the data party 110 and the service provider 120. The data and information stored in the permission chain can include permission data, permission chain smart contract, etc.

[0041] The service provider 120 can be any participant providing medical data sharing services, and the functions of the service provider 120 are implemented by the processing device of the service provider 120. In some embodiments, the data party 110 can receive the data request and the user public key and other information sent by the user through the user terminal 140 through the service provider 120, and perform relevant operations according to these information, for example, providing the private data requested by the user through the service provider 120. In some embodiments, the data party 110 can exchange data and / or information with other components (for example, the service provider 120, the permission chain system 130, the user terminal 140) in the system 100 through the network 150. In some embodiments, one or more components (for example, the permission chain system 130, the user terminal 140) in the system 100 can be included in the data party 110.

[0042] The service provider 120 can process data and / or information obtained from other device or system components, perform the medical data sharing method shown in some embodiments of the present specification based on the data, information and / or processing results, and complete one or more functions described in some embodiments of the present specification. For example, the service provider 120 can verify whether the user has the relevant permission corresponding to the target medical data based on the data request for the target medical data and the user public key and other information sent by the user terminal 140. For another example, after the user is verified, the service provider 120 can perform corresponding operations on the target medical data on the private data chain of the data party 110 based on the data request of the user, and return the operation result to the user through the user terminal 140. In some embodiments, the service provider can include various entities capable of obtaining medical institution data, such as government regulatory agencies, public service agencies, medical insurance agencies, etc. In some embodiments, the service provider 120 can include one or more processing devices similar to the data party. In some embodiments, the service provider 120 can exchange data and / or information with other components in the system 100 (e.g., the data party 110, the permission chain system 130, the user terminal 140) through the network 150. In some embodiments, the service provider 120 can be directly connected with other components in the system 100 (e.g., the permission chain system 130, the user terminal 140). In some embodiments, one or more components in the system 100 (e.g., the permission chain system 130, the user terminal 140) can be included in the service provider 120.

[0043] The user terminal 140 can realize the interaction of the user with other system components. In some embodiments, the user can include a hospital patient, a medical staff, a government regulatory agency, a scientific research staff, a public service agency, a medical insurance agency, etc. In some embodiments, the user can send a data request and a user public key and other information to the service provider 120 through the user terminal 140 to access private data in the private data chain of the data party 110, such as private medical data, etc. In some embodiments, the user terminal 140 can receive the requested target data, such as target medical data, etc. from the service provider 120. In some embodiments, the user terminal 140 can be one of a mobile device 140-1, a tablet computer 140-2, a laptop computer 140-3, a desktop computer 140-4 and other devices with input and / or output functions, or any combination thereof.

[0044] Network 150 can connect components of the system and / or connect the system with external resource parts. Network 150 enables communication between components and with other parts outside the system, facilitating exchange of data and / or information. In some embodiments, one or more components in system 100 (e.g., data party 110, service provider 120, permission chain system 130, user terminal 140) can send data and / or information to other components through network 150. In some embodiments, network 150 can be any one or more of a wired network or a wireless network.

[0045] It should be noted that the foregoing description is only illustrative of the application and not intended to be limiting. Various alternatives and modifications will become apparent to those skilled in the art from consideration of the specification and drawings. It will be apparent to those of ordinary skill in the art that features, components, structures, methods and other features described herein can be combined in various ways. For example, data party 110, service provider 120 can be based on a cloud computing platform, such as public cloud, private cloud, community cloud, and hybrid cloud, etc. However, such variations and modifications will not depart from the scope of the present specification.

[0046] Figure 2 is a schematic diagram of a medical data sharing system according to some embodiments of the present specification.

[0047] As Figure 2 shown, in some embodiments, medical data sharing system 200 can be applied to a service provider (e.g., service provider 120), including an obtaining module 210, a verifying module 220, and an accessing module 230.

[0048] In some embodiments, obtaining module 210 can be configured to obtain a data request of a user about target medical data and a user public key of the user.

[0049] In some embodiments, verifying module 220 can be configured to perform user verification of the user, including: interacting with a permission chain shared by a plurality of data parties to verify, based on the user public key, whether the user has relevant permissions corresponding to the target medical data through the permission chain, the permission chain storing user permission information.

[0050] In some embodiments, accessing module 230 can be configured to, when the user verification is passed, access a private data chain of a data party (e.g., data party 110) and perform an operation related to the data request on the target medical data on the private data chain, the private data chain storing private medical data of the data party.

[0051] Figure 3 is an exemplary flowchart of a medical data sharing method according to some embodiments of the present specification.

[0052] As shown in Figure 3 FIG. 3, the process 300 can include the following steps. In some embodiments, the process 300 can be performed by any one of the service provider 120, the service provider 320, the service provider 440, the application layer 510, the application layer 620, the system 720, the system 830, the institution 940, the institution 950. Figure 3 In some embodiments, the process 300 is performed by the service provider 320 is taken as an example for illustration.

[0053] At step S315, a data request of the user about the target medical data and a user public key are obtained. In some embodiments, the step S315 can be performed by the obtaining module 210.

[0054] The user refers to a person or entity that needs to access the private data of a data provider (i.e., a data party), such as a hospital patient, a medical staff, a government regulatory agency, a scientific research staff, a public service institution, a medical insurance institution, etc. The target medical data refers to private medical data belonging to the data party. In some embodiments, the target medical data can be stored on a private data chain that is private to the data party. In some embodiments, the service provider 320 can include the service provider 120.

[0055] In some embodiments, the service provider 320 can obtain the data request of the user 310 about the target medical data and the user public key from the user 310. The data request can include information of the data to be accessed, such as a data name, a number, etc. The user public key refers to a public key used by the user in asymmetric encryption, such as a digital certificate, etc. In some embodiments, the data request can also include operation information of the data to be accessed, such as reading, writing, modifying, etc.

[0056] At step S325, user verification of the user is performed. In some embodiments, the step S325 can be performed by the verification module 220.

[0057] In some embodiments, the data party can include one or more, such as the hospital 910, the hospital 920, and the hospital 930 in Figure 9 In some embodiments, the service provider can include one or more, such as the institution 940 and the institution 950 in Figure 9 In some embodiments, the plurality of data parties can include a public permission chain. In some embodiments, the data party and the service provider can own the public permission chain. For example, the hospital 910, the hospital 920, the hospital 930, the institution 940, and the institution 950 in Figure 9 In some embodiments, the plurality of data parties can include a public permission chain. In some embodiments, the data party and the service provider can own the public permission chain. For example, the hospital 910, the hospital 920, the hospital 930, the institution 940, and the institution 950 in

[0058] In some embodiments, the service provider 320 can perform user verification on the user 310 based on the obtained user public key, where the user verification can include verifying whether the user 310 has relevant permissions corresponding to the target medical data, and whether the user identity of the user 310 is consistent with the user public key.

[0059] The relevant permissions refer to permissions related to accessers and data operations of the target medical data. In some embodiments, the user can be divided into multiple groups according to attributes, such as accessers, patients, data parties, departments, etc. In some embodiments, the relevant permissions can be determined based on user grouping, including at least one of accesser-related permissions, patient-related permissions, data party-related permissions, department-related permissions, data operation permissions, etc. The patient-related permissions can include access permissions that the patient has for the data, such as which data can be accessed, data operation permissions for the accessible data, etc. The data party-related permissions can include access permissions that the data party (e.g., the medical institution where the patient is located) has for the data. The department-related permissions can include access permissions that the department of the medical institution where the patient is located has for the data. The accesser-related permissions can include access permissions that other accessers other than the patient, the data party, and the department have for the data. The data operation permissions can include at least one of data reading permissions, data writing permissions, and data modification permissions, such as read-only, read-write, and read-write and modification.

[0060] In some embodiments, the service provider 320 can interact with a public permission chain 321 shared by multiple data parties, and the public permission chain 321 can verify user data-related permissions based on the user public key, i.e., verify whether the user 310 has relevant permissions corresponding to the target medical data. Wherein the user permission information is stored on the permission chain. In some embodiments, the user permission information can include a pre-stored user public key and a user group corresponding to the user public key, where the user group can include data access permissions corresponding to the group. In some embodiments, the public permission chain 321 can determine the user group according to the obtained user public key, and determine the data access permissions that the user has according to the user group.

[0061] In some embodiments, the permission chain can include a permission verification smart contract for verifying whether a user has a specific permission. In some embodiments, the public permission chain 321 can verify, through the permission verification smart contract, whether the user 310 has the relevant permission corresponding to the target medical data based on the user public key and the relevant information of the target medical data. In some embodiments, the permission verification smart contract can find the corresponding user group based on the user public key, obtain the corresponding user permission information according to the user group, and determine whether the user has the relevant permission of the target medical data based on the found user permission information. For example, the patient department doctor A sends the department public key B and the data modification request for the medical data C to the service provider 320; the service provider 320 sends these information to the public permission chain 321; the public permission chain 321 matches the department public key B with the public key E of the department group pre-stored on the permission verification smart contract, and the matching is successful; then the public permission chain 321 obtains the user permission information of the department group, i.e., the department related permission; determines whether the medical data C is within the scope of the department data access permission and whether the modification operation on the medical data C is allowed; if the results are both yes, it is determined that the patient department doctor A has the modification permission of the requested medical data C.

[0062] In some embodiments, the user verification of the user can also include verifying whether the user identity of the user is consistent with the user public key, and if the user identity of the user is consistent with the user public key, it means that the identity of the user is real and consistent with the identity claimed by the user, wherein the identity claimed by the user can be obtained from the user public key provided by the user. For example, the user public key provided by the user is the public key of the department group stored on the permission chain, and the claimed identity of the user is a patient department doctor. In some embodiments, the service provider 320 further includes a zero-knowledge proof layer 322, which can be used to verify the user identity through zero-knowledge proof. Zero-knowledge proof means that the proof information provided by the user in the verification process does not involve personal privacy and other non-public information. In some embodiments, after the public permission chain 321 verifies the user data related permission, the zero-knowledge service layer 322 can verify whether the user identity of the user is consistent with the user public key through zero-knowledge proof. In some embodiments, the zero-knowledge proof can include interactive zero-knowledge proof, non-interactive zero-knowledge proof, etc. The related content of the interactive zero-knowledge proof can be referred to the related description of Figure 7 , and the related content of the non-interactive zero-knowledge proof can be referred to the related description of Figure 8 , which will not be described here.

[0063] In some embodiments of the present specification, the user is authenticated by zero-knowledge proof, without the need for the user to use a traditional login mechanism, i.e., inputting his own password or private key, thereby achieving authentication of the identity of the visitor without the user providing any personal privacy information, ensuring that sensitive information such as the user's password or private key is not leaked, and protecting the personal privacy security of the user.

[0064] In some embodiments, the verification strength and user verification method can be determined according to the security requirements of the target medical data. Specifically, for different target medical data, there can be different security requirements, and different verification strengths and user verification methods can be determined according to the different security requirements of different target medical data.

[0065] In some embodiments, the service provider 320 can determine a security coefficient corresponding to the data request based on the relevant information of the target medical data requested by the user 310, the type of data operation requested, etc., and determine the type of permission verification of the user according to the security coefficient, wherein the type of permission verification can represent the verification strength. For example, the verification strength can be low, medium, high, etc., and the greater the security coefficient value, the higher the corresponding verification strength.

[0066] In some embodiments, the security coefficient c can be determined in the following way: assuming that the target medical data corresponds to a security coefficient a and the operation type corresponds to a security coefficient b, then a*b is taken as the security coefficient c corresponding to the data request. Wherein the security coefficient a corresponding to the target medical data = (the security coefficient of the patient corresponding to the target medical data + the security coefficient of the hospital where the target medical data is located + the security coefficient of the department where the target medical data is located) / 3.

[0067] In some embodiments, the security coefficient can be predicted in various ways such as models or algorithms. In some embodiments, the service provider 320 can obtain the security coefficient corresponding to the data request by a prediction model based on the historical behavior data of the user 310 (for example, data information, data operation information, user verification information, data operation result information, feedback information of data parties and other participants to the user data operation, etc. in historical data requests). Specifically, the prediction model can learn the user characteristics of the user based on the historical behavior data of the user 310; based on the user characteristics, the feature information of the data request of the user this time (for example, the patient type corresponding to the target medical data requested, the hospital type where it is located, the department type where it is located, the operation type, etc.), the security coefficient corresponding to the data request this time is obtained.

[0068] In some embodiments, the predictive model can be a machine learning model, such as a decision tree or neural network model. In some embodiments, the predictive model can be trained based on training samples and corresponding labels obtained from historical user behavior data, and the model can be trained based on the training samples and corresponding labels. The labels can be determined manually. For example, the higher the security coefficient label value, the greater the number of times a user fails verification, the greater the number of times errors are reported in the data manipulation results for the same type of requested data, and the greater the number of times the feedback from data providers and other participants is unacceptable regarding the user's data manipulation.

[0069] In some embodiments, the service provider 320 may send relevant information about the target medical data, the type of data operation requested by the user 310, and the type of permission verification for the user 310 to the public permission chain 321.

[0070] In some embodiments, the smart contract on the public permission chain 321 can determine the method corresponding to the permission verification type for user 310 from a set of preset permission verification methods, and then verify whether user 310 has the corresponding permissions based on the determined permission verification method. Specifically, these permission verification methods may include:

[0071] If the permission verification type for user 310 corresponds to a high verification strength, then verify whether user 310 has data-related permissions. Also, if user 310 has data-related permissions, obtain the user's historical verification data, which may include the historical verification pass rate. Verify whether the user's historical verification pass rate is greater than a first threshold, where the first threshold is a relatively high value, such as 95%, 99%, etc.

[0072] If the verification type corresponding to the verification strength of user 310 is medium, then verify whether user 310 has data-related permissions. Also, when user 310 has data-related permissions, obtain the user's historical verification data, which may include the historical verification pass rate. Verify whether the user's historical verification pass rate is greater than a second threshold, where the second threshold is less than the first threshold, for example, 75%, 80%, etc.

[0073] If the verification type for user 310 corresponds to low verification strength, then verify whether user 310 has data-related permissions.

[0074] In some embodiments, after user 310's user authentication is successful, service provider 320 can execute step S335 to access the data provider's private data. In some embodiments, if user 310's user authentication fails, service provider 320 can send a prompt message to user 310, which may include the authentication result, the reason for the failed authentication, etc.

[0075] At step S335, the private data chain of the data party is accessed, and the target medical data is operated in relation to the data request on the private data chain. The private data chain stores private medical data of the data party. In some embodiments, step S335 can be performed by the access module 230.

[0076] In some embodiments, after the user verification is passed, the user 310 can access the data party private data chain 330 through the service provider 320, and perform operations related to the data request on the data party private data chain 330. For example, at least one of reading, modifying, etc. operations on the private medical data on the data party private data chain 330. For another example, writing new medical data on the data party private data chain 330.

[0077] In some embodiments of the present specification, the medical data and the permissions are stored by the principle of blockchain decentralization, which can avoid the problem of all data loss caused by damage to a traditional database, and can avoid the situation that the centralized data flow and operation can be tracked, thereby improving the security and traceability of the data; by using the "encrypted data chain (private) + permission chain (public)", multiple users (e.g., hospital patients, medical staff, government regulatory agencies, scientific research personnel, public service agencies, and medical insurance agencies, etc.) can propose medical data reading, writing, or modification applications to the data party through the service provider, which ensures that each party can access and operate the encrypted medical data according to their respective permissions in the permission chain, thereby improving the accessibility of the data and realizing cross-hospital medical data sharing.

[0078] In some embodiments, the data interaction with the private data chain is performed through network encryption transmission. For example, data interaction with the user can be performed through an HTTPS secure transmission encryption channel to realize reading, writing, or modifying operations on the private medical data on the private data chain.

[0079] In some embodiments, the private medical data on the private data chain can include anonymized medical data. Anonymized medical data refers to medical data that hides or eliminates patient information such as patient identity / identification. In some embodiments, the anonymized medical data can be generated by a smart contract algorithm on the private data chain. Specifically, when private medical data is packaged and stored on the private data chain, a preset proportion of the private medical data can be anonymized to obtain anonymized medical data. In some embodiments, anonymizing medical data can include removing and randomly replacing patient information such as patient identity / identification in the data to obtain original anonymized medical data; and encrypting the original anonymized medical data through a public key of an anonymous account and storing it under the anonymous account. In some embodiments, the anonymous accounts of various data parties can be unified. In some embodiments, when a user needs to access anonymized medical data, the user can be verified, and after verification, the data is decrypted with the anonymous account private key at the time of encryption, thereby realizing access to anonymized medical data.

[0080] In some embodiments, each data party can access the anonymized medical data of other data parties through data access permission non-fungible tokens. In some embodiments, data parties can obtain the permission through an incentive mechanism deployed on the permission chain and / or the private data chain. For more information about the incentive mechanism and how to access anonymized medical data, please refer to the related description of Figure 4 , which will not be repeated here.

[0081] Figure 4 is a schematic diagram of a medical data sharing method according to some embodiments of the present specification.

[0082] In some embodiments, access to anonymized medical data can be achieved by performing the method shown in flow 400 as shown in Figure 4 . For specific purposes such as scientific research, only health-related data of patients is needed. If patient identity information is also provided, it may lead to leakage of patient information and cause unnecessary risks to the privacy and security of patients. Through anonymized medical data, data parties can shield patient identity information, and data recipients can only obtain patient health data, but cannot associate it with patient identity, thereby avoiding leakage of patient identity information and health information, protecting the personal privacy of patients, and ensuring the demand for medical data in specific situations such as scientific research.

[0083] In some embodiments, the data access right non-fungible token can also be referred to as a data access right NFT, and can be used by a data party to access anonymized medical data on a private data chain of another data party by holding the data access right non-fungible token. In some embodiments, the data access right non-fungible token can include a non-fungible token (NFT) or the like for identifying access rights. In some embodiments, the data access right non-fungible token can be obtained through an incentive mechanism, where the incentive mechanism can include an incentive mechanism deployed on a private data chain and / or an incentive mechanism deployed on a permission chain.

[0084] In some embodiments, a data party can store its own private medical data on its private data chain and deploy an incentive mechanism on the private data chain. The incentive mechanism on the private data chain can be implemented by a smart contract, including: when a first preset number of private medical data is packaged and stored on the private data chain, a second preset number of data access right non-fungible tokens are automatically generated on the private data chain.

[0085] In some embodiments, the first preset number can be determined according to at least one of the number of packaged medical data, the storage space occupied by the packaged medical data, and the like. In some embodiments, the second preset number can be determined according to the first preset number. For example, the first preset number can be 5 packaged medical data, and the second preset number can be 1 NFT. For another example, the first preset number can be 1 GB of packaged medical data, and the second preset number can be 2 NFTs.

[0086] In some embodiments, a plurality of data parties can store user permission information on a public permission chain and deploy an incentive mechanism on the permission chain. The incentive mechanism on the permission chain can be implemented by a smart contract, including: when a third preset number of user permission information is packaged and stored by a data party on the permission chain, a fourth preset number of data access right non-fungible tokens are automatically generated on the permission chain and assigned to the data party.

[0087] In some embodiments, the third preset number can be determined according to at least one of the number of packaged user permission information, the storage space occupied by the packaged user permission information, and the like. In some embodiments, the fourth preset number can be determined according to the third preset number. For example, the third preset number can be 3 packaged user permission information, and the fourth preset number can be 1 NFT. For another example, the third preset number can be 100 MB of packaged user permission information, and the fourth preset number can be 2 NFTs.

[0088] In some embodiments, a data party can access anonymized medical data on a private data chain of another data party by holding the data access right non-fungible token. For example, a data party can access anonymized medical data on a private data chain of another data party by holding a data access right non-fungible token.Figure 4 As shown, the other data party can be data party B 430, and data party A 410 can access the anonymized medical data on the data party B private data chain 450 through the data access permission NFT held by data party A 410.

[0089] In some embodiments, data party A 410 can sign the data access permission NFT of data party A 410 based on the private key of data party A 410 to obtain a signed data access permission NFT 420.

[0090] In some embodiments, data party A 410 can send the signed data access permission NFT 420 and the anonymized data access request to data party B 430 or the service provider 440. The anonymized data access request can include the public key of data party A 410.

[0091] In some embodiments, after receiving the signed data access permission NFT 420 and the anonymized data access request, data party B 430 or the service provider 440 can perform data access permission verification based on the public key of data party A 410. The data access permission verification can be performed in a manner similar to user verification, which can be referred to in the related description of step S325 of Figure 3 , and will not be described here again.

[0092] In some embodiments, when the data access permission verification is passed, data party B 430 or the service provider 440 can allow data party A 410 to access the anonymized medical data of data party B 430, i.e., the anonymized medical data on the data party B private data chain 450.

[0093] Figure 5 is a schematic diagram of a medical data sharing system according to some embodiments of the present specification.

[0094] As shown in Figure 5 , in some embodiments, the medical data sharing system 500 can include an application layer 510, a permission layer 520, a zero-knowledge proof layer 530, and a data layer 540. Figure 5 In

[0095] In some embodiments, a user (i.e., a visitor) can access medical data on a private encrypted data chain of the hospital or across hospitals through the application layer 510. When the user accesses the encrypted data chain, the application layer 510 can transmit the public key of the user and information such as the hospital and department to which the accessed data belongs to the permission layer 520. The system will verify the read, write, or modification permission of the user on the medical data of the hospital, the department, and the patient according to the public key of the user in the permission layer.

[0096] In some embodiments, the application layer 510 can be used for multiple individual or entity users to perform data operations on medical data on the encrypted data chain in the data layer 540, where the data operations can include at least one of data reading, data writing, data modification, etc. In some embodiments, the application layer 510 can include various users. As shown, the users of the application layer 510 can include hospital patients, medical staff, government regulatory agencies, research staff, public service agencies, medical insurance agencies, etc. In some embodiments, the application layer 510 can send data requests and user public keys, etc. issued by the users to the permission layer 520 for user verification, where the data requests can include information of target medical data accessed, data operations on the data, etc. Figure 5

[0097] In some embodiments, the permission layer 520 can be used to store and verify related permissions of users to access and modify patient (i.e., patient) data, where the related permissions can include at least one of patient-related permissions, data party-related permissions, department-related permissions, data operation permissions, etc. In some embodiments, the permission layer 520 can include a permission chain 521 commonly owned by multiple parties, where the multiple parties can include medical institutions (e.g., hospitals, clinics, physical examination institutions, etc.) and third-party institutions (e.g., government regulatory agencies, public service agencies, medical insurance agencies, etc.). For example, as shown, the multiple parties can include hospitals 910-930 and institutions 940-950, and the permission chain 901 is commonly owned by the multiple parties. In some embodiments, the medical institutions in the multiple parties can be data parties, and the third-party institutions can be service providers. Figure 9

[0098] In some embodiments, the permission chain 521 can be a public blockchain, and the modules in the permission chain 521 can include contract algorithms, incentive mechanisms, consensus mechanisms, P2P network communications, and permission data.

[0099] ​​In some embodiments, the contract algorithm module in the permission chain 521 can be used to deploy a blockchain contract that records and stores permissions, which contains the attribute group of the user and the control policy for adding and deleting permissions. In some embodiments, the attribute group of the user can be obtained based on the public key of the user. In some embodiments, the attribute group of the user can include the visitor public key, the patient public key, the hospital where the patient is located, the department where the patient is located, the data operation level, etc.; the data operation level can include read-only, read-write, read-write and modification. In some embodiments, the control policy for adding and deleting permissions of the permission chain can include hierarchical division of operation attributes of medical data; the operation attributes corresponding to the user are determined according to the attribute group of the user. In some embodiments, the control policy for adding and deleting permissions can be formulated by a unified permission chain contract algorithm, that is, the control policy is written into the contract algorithm, and the control policy for adding and deleting permissions is realized through the contract, thereby realizing decentralized discretization.

[0100] In some embodiments, the consensus mechanism module in the permission chain 521 can be used to provide unified rules and standards for the addition of data and the legality verification between blockchains.

[0101] In some embodiments, the incentive mechanism module in the permission chain 521 can be used to provide scientific research access to anonymized medical data within a preset time period for a data party (e.g., a medical institution) that successfully packages permission data. In some embodiments, the incentive mechanism for packaging permission data can be formulated by a unified permission chain contract. Taking a hospital as an example, specifically, the hospital successfully packages a third preset number of user permission information each time, and the incentive mechanism module can automatically generate a fourth preset number of data access permission non-fungible tokens (NFTs) for the hospital scientific research personnel to access anonymized patient data across hospitals within a certain time (e.g., 1 access permission NFT can access 10 non-repeated anonymized patients within 30 minutes). Wherein, the generation mechanism of anonymized patient data can be defined by an encrypted data chain contract algorithm, that is, during the packaging of medical data by the data chain, the patient data will be automatically anonymized according to a preset proportion (e.g., 5%, 10%, etc.), the identity / identifier of the data is removed and randomly replaced, stored under a unified anonymous account, and encrypted through the public key of the anonymous account. When a user needs to access anonymized patient data, the user is verified, and after the user verification is passed, the data is decrypted with the private key of the anonymous account, thereby realizing access to anonymized data.

[0102] In some embodiments, the P2P network communication module in the permission chain 521 can be used for data communication and transmission between permission chain nodes and between the permission chain and the outside through the P2P mode. In some embodiments, the data interaction of the P2P network communication module with other parties can be carried out through network encryption transmission (e.g., HTTPS).

[0103] In some embodiments, the permission data modules in the permission chain 521 can be used to store packaged user permission data, etc.

[0104] In some embodiments, the zero-knowledge proof layer 530 can be used to verify whether the user identity is consistent with the submitted user public key, and the process does not require the user to provide any data that may leak his privacy. After the identity verification of the visitor, the visitor can obtain the data operation permission of the target medical data. In some embodiments, after verifying that the user has the relevant permission of the target medical data, the permission layer 520 can send the user public key and other information to the zero-knowledge proof layer 530 to verify whether the user identity of the user is consistent with the user public key. In some embodiments, the zero-knowledge proof layer 530 can include interactive zero-knowledge proof 531 and non-interactive zero-knowledge proof 532. The interactive zero-knowledge proof 531 can verify whether the user identity of the user is consistent with the user public key through the interactive zero-knowledge proof manner. The non-interactive zero-knowledge proof 532 can verify whether the user identity of the user is consistent with the user public key through the non-interactive zero-knowledge proof manner. For related content of the interactive zero-knowledge proof, please refer to the related description of Figure 7 , and for related content of the non-interactive zero-knowledge proof, please refer to the related description of Figure 8 , which will not be repeated here. In some embodiments, after the verification of the user identity by the zero-knowledge proof layer 530, the user can access the target medical data in the data layer 540.

[0105] In some embodiments, the data layer 540 can be used for the data party (i.e. the hospital) to store private patient information and medical data using the private data chain of the party. Wherein, the data is encrypted by the public key of the data party before being chained. In some embodiments, the data layer 540 can include multiple data parties, i.e. A hospital, B hospital, C hospital, etc., each data party can include a private encrypted data chain of the hospital, and the encrypted data chains among the data parties are independent of each other, for example, A hospital includes an encrypted data chain 541.

[0106] In some embodiments, the encrypted data chain 541 can be decentralized by multiple in-hospital servers, and the modules in the encrypted data chain 541 can include medical data, P2P network communication, consensus mechanism, incentive mechanism and contract algorithm.

[0107] In some embodiments, the contract algorithm module in the encrypted data chain 541 can be used to deploy a data chain contract. In some embodiments, the control policy for adding or deleting data can be formulated by the data chain contract algorithm. In some embodiments, the data chain contract algorithm can include a property group of data, data content, and a control policy for adding or deleting data. The property group of data is determined according to the identification (e.g., ID) of the data, and the properties of the property group can include a patient public key, a hospital where the patient is located, a department where the patient is treated, data content, and operation permissions, etc. The control policy of the data chain includes dividing the department where the medical data is located, and determining the properties of the data according to the department attributes. In some embodiments, the department can include internal medicine, surgery, obstetrics, pediatrics, emergency department, oncology, infectious department, pharmacy department, laboratory department, radiology department, etc.

[0108] In some embodiments, the incentive mechanism module in the encrypted data chain 541 is used to provide a certain period of scientific research access to anonymized medical data to the data party who successfully packages the encrypted medical data. In some embodiments, the incentive mechanism for packaging medical data can be formulated by a unified data chain contract. Taking a hospital as the data party as an example, specifically, the hospital successfully packages a first preset number of encrypted medical data each time, and the incentive mechanism module can automatically generate a second preset number of data access right non-fungible tokens for the hospital scientific research personnel to access anonymized patient data across hospitals within a certain period of time. The generation mechanism of anonymized patient data, etc. can refer to the related description in the permission chain 521, which will not be described here.

[0109] In some embodiments, the consensus mechanism module in the encrypted data chain 541 can be used to provide unified rules and standards for data addition and legitimacy verification between blockchains.

[0110] In some embodiments, the P2P network communication module in the encrypted data chain 541 can be used for data communication and transmission between encrypted data chain nodes and between the encrypted data chain and the outside through the P2P mode. In some embodiments, after the user identity is verified, the data party can use the private key of the party to decrypt the encrypted medical data, and the P2P network communication module can interact with the user through network encryption transmission (e.g., HTTPS) to make the user can perform operations related to data requests on the target medical data.

[0111] In some embodiments, the medical data module in the encrypted data chain 541 can be used to store packaged medical data, etc.

[0112] Figure 6 is an exemplary flowchart of a medical data sharing method according to some embodiments of the present specification.

[0113] As Figure 6As shown, in some embodiments, a user 610 can access target medical data on a data layer 650 through a process 600. The medical data sharing system can be composed of an application layer 620, an authority chain 630, a zero-knowledge proof layer 640, and the data layer 650. In some embodiments, the system can correspond to the medical data sharing system 500, where the application layer 620 corresponds to the application layer 510, the authority chain 630 corresponds to the authority layer 520, the zero-knowledge proof layer 640 corresponds to the zero-knowledge proof layer 530, the interactive zero-knowledge proof 641 corresponds to the interactive zero-knowledge proof 531, the non-interactive zero-knowledge proof 642 corresponds to the non-interactive zero-knowledge proof 532, and the data layer 650 corresponds to the data layer 540. The process 600 can include the following steps.

[0114] At step S615, the user issues a data request and provides a user public key.

[0115] In some embodiments, the user 610 can issue a data request for target medical data and a user public key to the application layer 620. After step S615, the user can be verified through step S625 and step S635. For more information on how to obtain a data request and a user public key, please refer to the relevant description of step S315, which will not be repeated here.

[0116] At step S625, the data-related authority of the user is verified.

[0117] In some embodiments, the application layer 620 can send the data request for the target medical data and the user public key to the authority chain 630 to verify the data-related authority of the user. For more information on how to verify the data-related authority of the user, please refer to the relevant description of step S325, which will not be repeated here.

[0118] At step S635, the identity of the user is confirmed.

[0119] In some embodiments, after the data-related authority of the user is verified by the authority chain 630, the identity of the user can be further confirmed by the zero-knowledge proof layer 640 to be consistent with the user public key. For more information on how to verify the identity of the user, please refer to the relevant description of step S325, which will not be repeated here. In some embodiments, the zero-knowledge proof layer 640 can verify the identity of the user through the interactive zero-knowledge proof 641 or the non-interactive zero-knowledge proof 642. For more information on the interactive zero-knowledge proof, please refer to the relevant description of Figure 7 , and for more information on the non-interactive zero-knowledge proof, please refer to the relevant description of Figure 8 , which will not be repeated here.

[0120] At step S645, the private medical data is accessed after the identity is confirmed.

[0121] In some embodiments, after the user identity is verified, the user 610 can access the private medical data, i.e., the target medical data, in the data layer 650.

[0122] Step S655, the user performs data operation.

[0123] In some embodiments, after the user 610 is allowed to access the private medical data in the data layer 650, the user can perform corresponding data operation, such as reading, writing, modifying, etc., on the data through the application layer 620. For more information about how to access data request and perform operation on data, please refer to the relevant description of step S335, which will not be repeated here.

[0124] In some embodiments of the present specification, the private encrypted data chain and the public permission chain replace the traditional public chain, and the multi-party user can apply for reading, writing or modifying medical data to the data layer through the application layer, so as to ensure that the hospital patients, medical staff, government regulatory agencies, scientific research personnel, public service agencies and medical insurance agencies and other related users can access and operate the encrypted medical data according to their respective permissions in the permission chain, realize cross-hospital data sharing, and improve the connectivity of data.

[0125] Figure 7 is an exemplary flowchart of the method for confirming user identity according to the interactive zero-knowledge proof shown in some embodiments of the present specification.

[0126] In some embodiments, the interactive zero-knowledge proof, such as the interactive zero-knowledge proof 531, the interactive zero-knowledge proof 641, can be implemented by performing the steps shown in flow 700. In some embodiments, the flow 700 can include the following steps. In some embodiments, the flow 700 can be performed by the zero-knowledge proof layer in the medical data sharing system, such as the zero-knowledge proof layer 322, the zero-knowledge proof layer 530, the zero-knowledge proof layer 640.

[0127] Step S715, the user provides his own public key.

[0128] In some embodiments, the user 710 can provide the user public key, i.e., the user's own public key, to the medical data sharing system 720. In some embodiments, the system 720 can include the medical data sharing system 100, the medical data sharing system 200, the medical data sharing system 500, the medical data sharing system 900, etc., and the user 710 can include the user 310, the user 610, etc.

[0129] Step S725, the system generates a random number.

[0130] In some embodiments, the medical data sharing system can generate a random number in various ways (e.g., a random number generation algorithm, etc.), such as Figure 7 As shown, the system 720 can generate a random number X1 730 in various ways.

[0131] At step S735, the system encrypts the random number using the user's public key.

[0132] In some embodiments, the medical data sharing system can encrypt the random number based on the user's public key to obtain a first ciphertext. As shown, Figure 7 As shown, the system 720 can encrypt the random number X1 730 using the public key of the user 710 to obtain a ciphertext S1 740 (i.e., the first ciphertext). The encryption algorithm can include various asymmetric encryption algorithms, such as RSA, DSA, ECC, Diffie-Hellman, El Gamal, etc.

[0133] At step S745, the system returns the encrypted ciphertext to the user.

[0134] In some embodiments, the system 720 can return the ciphertext S1 740 to the user 710.

[0135] At step S755, the user decrypts the ciphertext using his own private key.

[0136] In some embodiments, the medical data sharing system can obtain a first decryption result obtained by the user decrypting the first ciphertext using the user's private key. As shown, Figure 7 As shown, the user 710 can decrypt S1 740 using the user's private key (i.e., the private key of the user 710) to obtain a decrypted number X2 750 (i.e., the first decryption result), and send the decrypted number X2 750 to the system 720.

[0137] At step S765, the system compares the random number and the decrypted number to confirm the user's identity.

[0138] In some embodiments, the medical data sharing system can determine that the user's identity is consistent with the user's public key in response to the random number being consistent with the first decryption result. As shown, Figure 7 As shown, the system 720 can compare the random number X1 730 and the decrypted number X2 750, and if the two are the same, it confirms that the user's identity is consistent with the user's public key, i.e., the user's real identity is consistent with the identity he claims.

[0139] Figure 8 is an exemplary flowchart of a method for confirming a user's identity according to the non-interactive zero-knowledge proof shown in some embodiments of the present specification.

[0140] In some embodiments, a non-interactive zero-knowledge proof, e.g., the non-interactive zero-knowledge proof 532, the non-interactive zero-knowledge proof 642, can be implemented by performing steps as shown in the flow 800. In some embodiments, the flow 800 can include the following steps. In some embodiments, the flow 800 can be performed by a zero-knowledge proof layer in a medical data sharing system, e.g., the zero-knowledge proof layer 322, the zero-knowledge proof layer 530, the zero-knowledge proof layer 640.

[0141] At step S815, the user provides his own public key.

[0142] In some embodiments, the user 810 can provide the user public key K1 820 (i.e., the user’s 810 own public key) to the medical data sharing system 830. In some embodiments, the system 830 can include the medical data sharing system 100, the medical data sharing system 200, the medical data sharing system 500, the medical data sharing system 900, etc., and the user 810 can include the user 310, the user 610, etc.

[0143] At step S825, the user encrypts his own public key using his own private key.

[0144] In some embodiments, the user 810 can encrypt the user public key K1 820 using the user’s private key (i.e., the user’s 810 own private key) to obtain the ciphertext S2 840. In some embodiments, the encryption algorithm can include various asymmetric encryption algorithms, e.g., RSA, DSA, ECC, Diffie-Hellman, El Gamal, etc.

[0145] At step S835, the user sends the ciphertext to the system.

[0146] In some embodiments, the medical data sharing system can obtain the second ciphertext obtained by the user encrypting the user public key using the user’s private key. As shown in FIG. 8B, the system 830 can obtain the ciphertext S2 840 (i.e., the second ciphertext) sent by the user 810. Figure 8

[0147] At step S845, the system decrypts the ciphertext using the user’s public key.

[0148] In some embodiments, the medical data sharing system can decrypt the second ciphertext using the user public key to obtain a second decryption result. As shown in FIG. 8B, the system 830 can decrypt the ciphertext S2 840 using the user public key K1 820 to obtain the plaintext K2 850 (i.e., the second decryption result). Figure 8

[0149] At step S855, the system compares the user public key and the plaintext to confirm the user’s identity.

[0150] ​​In some embodiments, the medical data sharing system can determine that the user identity matches the user public key in response to the user public key being consistent with the second decryption result. As shown in Figure 8 FIG. 8, the system 830 can compare the user public key K1 820 and the translation K2 850, and if the two are the same, confirm that the user identity matches the user public key, i.e., the user real identity matches the identity it claims.

[0151] It should be noted that the above description of the processes 300, 400, 600, 700, 800 is merely for example and illustration, and does not limit the scope of the present specification. Those skilled in the art can make various modifications and changes to the processes 300, 400, 600, 700, 800 under the guidance of the present specification. However, these modifications and changes are still within the scope of the present specification. For example, step S625 and step S635 can be performed simultaneously. For another example, step S625 can be performed after step S635.

[0152] Figure 9 FIG. 9 is a schematic diagram of a network architecture of a medical data sharing system according to some embodiments of the present specification.

[0153] In some embodiments, the medical data sharing system can include a plurality of data parties and service providers. As shown in Figure 9 FIG. 9, in some embodiments, the medical data sharing system 900 can include a hospital 910, a hospital 920, a hospital 930, an institution 940, and an institution 950, wherein the hospital 910, the hospital 920, and the hospital 930 are data parties (e.g., the data party 110), and the institution 940 and the institution 950 are service providers (e.g., the service provider 120, the service provider 320). In some embodiments, the hospital 910, the hospital 920, the hospital 930, the institution 940, and the institution 950 can be connected through an encrypted data network (e.g., HTTPS, etc.). In some embodiments, the data parties and the service providers can include a public permission chain for storing user permission information. As shown in Figure 9 FIG. 9, the hospital 910, the hospital 920, the hospital 930, the institution 940, and the institution 950 can include a public permission chain 901. In some embodiments, each data party can include a private encrypted data chain of the party for storing private encrypted medical data of the party. As shown in Figure 9 FIG. 9, the hospital 910 includes a private data chain 912, the hospital 920 includes a private data chain 922, and the hospital 930 includes a private data chain 932.

[0154] The beneficial effects that the embodiments of the present specification can bring include but are not limited to: (1) the medical data and permissions are stored in a decentralized manner through the blockchain, which overcomes the problem that all data is lost due to damage to a traditional database, significantly improves the robustness of the data, and avoids the situation that the centralized data flow and operation are difficult to track, thereby improving the security and traceability of the data; (2) the user is authenticated through zero-knowledge proof, without providing any personal privacy information (for example, password or private key), which ensures the security of the personal privacy of the access user; (3) the private encrypted data chain and the public permission chain replace the traditional public chain, and the multi-party user can submit medical data access and operation requests to the data layer through the application layer, which ensures that the users of each related party (for example, hospital patients, medical staff, government regulatory agencies, scientific research personnel, public service agencies, medical insurance agencies, etc.) can conveniently access and operate the encrypted medical data in each medical institution according to their respective permissions in the permission chain, thereby realizing cross-hospital sharing of data among hospitals; (4) the attribute-based access control strategy is deployed in the blockchain contract of the permission chain and the private data chain, which ensures that in cross-hospital sharing, only the access user who meets the access permission can operate the data, so that the accuracy of cross-hospital data sharing is improved while the fine-grained data access is realized; (5) the preset proportion of data is automatically anonymized to generate anonymized data during the packaging of data in the permission chain and the private data chain, and the data access party accesses the anonymized data by means of the data access permission non-fungible token generated by the incentive mechanism on the blockchain, so that the patient's identity information can be shielded, and the data access party can only obtain the patient's health data, but cannot associate it with the patient's identity, thereby avoiding the leakage of the patient's identity information and health information, protecting the patient's personal privacy, and at the same time ensuring the demand for medical data in specific situations such as scientific research. It should be noted that different embodiments can have different beneficial effects, and in different embodiments, the beneficial effects that can be produced can be any one or a combination of the above, or any other beneficial effects that can be obtained.

[0155] The above has described the basic concepts, and it is obvious that the above detailed disclosure is only used as an example and does not limit the present specification. Although it is not explicitly stated here, those skilled in the art can make various modifications, improvements and corrections to the present specification. Such modifications, improvements and corrections are suggested in the present specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of the present specification.

[0156] Also, the use of "a" or "an" or "the" are intended to include both singular and plural, unless the context clearly indicates otherwise. Additionally, the use of "one or more" or "at least one" is intended to include one, two, three, four, or more, unless the context clearly indicates otherwise. Furthermore, the use of the term "including" as well as other forms for, e.g., "include", "includes," "included," and "includes," is intended to be broad and encompass the terms "comprising" and / or "consisting of." It will be understood by those within the art that throughout this disclosure the nomenclature used is for the purpose of

[0157] Also, the order of execution or performance of the elements of the processes disclosed herein is not limited to the order in which they are described unless otherwise specified. Further, the use of "for" or "while" loops are not intended to limit the implementation of the described processes to a single iteration unless otherwise specified. Additionally, the use of "first," "second," "third," etc. are not intended to indicate an order of importance, but rather an order of recitation unless otherwise specified.

[0158] Similarly, it is to be noticed that the term "comprising", used in the description, is not intended to exclude other elements or steps. It is to be understood that the elements or steps of the embodiments can also be implemented in software using any computer language, and a desired combination of hardware and software can be utilized. Further, it is to be noted that, unless otherwise specified, the description of the embodiments is intended to include both the hardware and software implementations.

[0159] Some embodiments use numerical designations to describe components, quantities of attributes. It is to be understood that such numerical designations used in the description of the embodiments are, in some examples, modified by the adjectives "about," "approximately," or "substantially." Unless otherwise indicated, "about," "approximately," or "substantially" indicates that the described numerical value allows for ±20% variation. Accordingly, numerical parameters in the description and claims are approximations, and can vary depending upon the requirements of the particular embodiment. In some embodiments, numerical parameters are determined by the use of standard techniques for making such determinations, such as the use of a standard number of significant digits. Although the numerical ranges and parameters setting forth the broad scope of the embodiments are approximations, the numerical values set forth in the specific examples are reported as precisely as practicable. The numerical values set forth in the specific examples are provided to be as precise as reasonably possible. However, some variations may

[0160] Each patent, patent application, patent publication, and other material cited in this specification is hereby incorporated by reference in its entirety herein for the teachings relevant to the sentence and / or paragraph in which the reference is presented. Document histories, to the extent not inconsistent with the pertinent U.S. patent application file history, are also incorporated by reference herein. To the extent that material incorporated by reference contradicts or contradicts any portion of this specification, including definition, the portion of the material incorporated by reference prevails. Note, however, that in the event of inconsistencies between any such material and the present specification, including definitions, the present specification, including definitions, will control.

[0161] Finally, it should be understood that the embodiments described herein are merely exemplary of the principles of the present description. Other embodiments can be devised without departing from the scope of the present description. Accordingly, the embodiments described herein are not intended to limit the scope of the present description, but rather are intended to be exemplary thereof.

Claims

1. A method for sharing medical data, applied to service providers, comprising: Obtain the user's data request regarding the target medical data and the user's public key; User verification of the user includes: interacting with a public permission chain of multiple data parties to verify whether the user has the relevant permissions corresponding to the target medical data based on the user's public key through the permission chain; the permission chain stores user permission information. Once the user verification is successful, access is granted to the data provider's private data chain, and operations related to the data request are performed on the target medical data within the private data chain. The private data chain stores the data provider's private medical data and is equipped with an incentive mechanism, which includes: When a first preset number of private medical data are packaged and stored on the private data chain, a second preset number of data access non-fungible tokens (NFTs) are automatically generated on the private data chain. The data access non-fungible tokens are used by the data party to access anonymized medical data on the private data chain of other data parties through the data access non-fungible tokens they hold. The data provider accesses the anonymized medical data on the private data chain of the other data providers through the following methods: Send a signed data access non-fungible token and an anonymous data access request to the other data party or the service provider, so that the other data party or the service provider verifies the data access non-fungible token based on the data party's public key. The signed data access non-fungible token is obtained by signing the data party's data access non-fungible token based on the data party's private key. Once the data access permission is verified using a non-fungible token, the other data party or the service provider allows the data party to access the anonymized medical data of the other data party.

2. The method as described in claim 1, wherein the relevant permissions include at least one of the following: patient-related permissions, data provider-related permissions, department-related permissions, and data operation permissions.

3. The method as described in claim 1, wherein verifying whether the user has the relevant permissions corresponding to the target medical data based on the user's public key through the permission chain includes: Based on the user's public key and relevant information about the target medical data, a permission verification smart contract is used to verify whether the user has the relevant permissions corresponding to the target medical data.

4. The method as described in claim 1, wherein the user verification of the user further includes: The user's identity is verified using zero-knowledge proof to determine whether the user's public key matches the user's identity.

5. The method as described in claim 4, wherein verifying whether the user's identity matches the user's public key using zero-knowledge proof includes: A random number is generated, and the random number is encrypted based on the user's public key to obtain the first ciphertext; Obtain the first decryption result obtained by the user using their private key to decrypt the first ciphertext; In response to the random number matching the first decryption result, it is determined that the user's identity matches the user's public key; or, Obtain the second ciphertext obtained by the user encrypting the user's public key using the user's private key; The second ciphertext is decrypted using the user's public key to obtain the second decryption result; In response to the user's public key matching the second decryption result, it is determined that the user's identity matches the user's public key.

6. The method of claim 1, wherein the private medical data includes anonymized medical data, the anonymized medical data being obtained through the following method: When the private medical data is packaged and stored on the private data chain, anonymized medical data is obtained by anonymizing a preset proportion of the private medical data; and The anonymized medical data is stored on the private data chain.

7. The method of claim 1, wherein the incentive mechanism is deployed on the permission chain, and the incentive mechanism further includes: When a third preset number of user permission information is packaged and stored by the data party on the permission chain, a fourth preset number of data access permission non-fungible tokens are automatically generated on the permission chain and allocated to the data party.

8. A medical data sharing system, applied to a service provider, comprising an acquisition module, a verification module, and an access module; The acquisition module is used to acquire the user's data request for target medical data and the user's public key; The verification module is used to perform user verification for the user, including: Interacts with a shared permission chain of multiple data providers to verify whether the user has the relevant permissions corresponding to the target medical data based on the user's public key through the permission chain. The permission chain stores user permission information. The access module is used to access the data provider's private data chain when the user authentication is successful, and to perform operations related to the data request on the target medical data on the private data chain. The private data chain stores the data provider's private medical data, and an incentive mechanism is deployed on the private data chain, the incentive mechanism including: When a first preset number of private medical data are packaged and stored on the private data chain, a second preset number of data access non-fungible tokens (NFTs) are automatically generated on the private data chain. The data access non-fungible tokens are used by the data party to access anonymized medical data on the private data chain of other data parties through the data access non-fungible tokens they hold. The data provider accesses the anonymized medical data on the private data chain of the other data providers through the following methods: Send a signed data access non-fungible token and an anonymous data access request to the other data party or the service provider, so that the other data party or the service provider verifies the data access non-fungible token based on the data party's public key. The signed data access non-fungible token is obtained by signing the data party's data access non-fungible token based on the data party's private key. Once the data access permission is verified using a non-fungible token, the other data party or the service provider allows the data party to access the anonymized medical data of the other data party.

Images