Intercloud cross-domain cooperation method and system for controlled access of global medical data

Abstract

The invention discloses an inter-cloud cross-domain cooperation method and system for controlled access of global medical data. The method comprises the following steps: a node A creates a transaction request according to an access attribute, carries out uplink and appoints a node B as a receiver; if yes, the node B generates an access token containing restriction information, binds the access token to the node A to generate transaction confirmation, and carries out uplink and appoints the node A as a receiver; the node A takes the access token as a credential for accessing data in the node B, and sends a data access request to the node B through a specified interface; and the node B verifies the access token carried in the data access request and controls whether the data access request is allowed or not. The invention aims to realize sharing and controlled access of global medical data in a cloud environment, eliminate data barriers among private clouds of different hospitals and promote data intercommunication and cooperation among different medical institutions, so that the need of repeated medical examination is reduced, the total data storage space is reduced, and the overall data utilization rate is improved.

Description

Technical Field

[0001] The present invention relates to the field of cloud computing technology, and in particular to a cloud cross-domain collaboration method and system for controlled access to global medical data. Background Art

[0002] With the continuous development of information technology, the digitalization and intelligence of hospitals has become an important trend in the development of the medical industry. However, on the one hand, with the continuous updating of technology, the data generated by medical units is growing in mass, and the types and amount of data are increasing. The global medical and health data has reached hundreds of Exabytes and is growing rapidly. A large tertiary hospital in China can perform 410,000 radiological and ultrasonic examinations a year, and the size of a single medical image has increased from 250MB to nearly 800MB; the size of a single file of pathological data ranges from hundreds of MB to several GB, and the hospital storage file capacity has exploded in 4 years, from tens of TB to hundreds of TB. According to relevant laws and regulations, the hospital's outpatient case storage time is not less than 15 years, and the inpatient case storage time is not less than 30 years, which puts great demands on the storage of medical institutions. On the other hand, due to the existence of hospital information islands, medical data is difficult to share and communicate, which inevitably leads to the problem of repeated medical examinations for patients in different hospitals, making the waiting time for medical treatment longer and the patient's medical expenses higher. At the same time, this also causes a waste of public medical resources and repeated consumption of national medical insurance funds. Therefore, how to effectively realize medical data sharing and controlled access, improve the utilization rate of medical data, and reduce the waste of medical resources has become one of the urgent problems to be solved in the current medical industry.

[0003] At present, according to the policy requirements of some regions, medical data needs to be uploaded to the national controlled institutions for unified storage. This method not only leads to double waste of storage capacity, but also brings great challenges to data carrying capacity. Due to the different structured and unstructured data storage architectures between different hospitals, even if the data is centrally stored, there are barriers. Cross-domain controlled access to medical data on the private clouds of different hospitals, especially cross-hospital sharing of medical imaging data, is extremely challenging. Therefore, to achieve cross-domain controlled access to medical data, it is necessary to solve the problems of medical data heterogeneity, data controlled access, and big data transmission. The storage formats of data on the private clouds of different hospitals are different, which makes it difficult to break the barriers between clouds; the identities of people from different institutions are complex, and patients circulate between multiple institutions. The sensitivity and privacy of medical data have great demands for identity access control; medical data, especially medical imaging data, is very large, and cross-hospital access requires a large amount of data transmission. A CT scan may generate hundreds to thousands of images, and the size of a single transmission may be several G. Taking 5G size and 100M bandwidth as an example, the image transmission delay is about 400 seconds. How to solve the delay of big data transmission is also an urgent problem to be solved. Summary of the invention

[0004] Technical problem to be solved by the present invention: In view of the above-mentioned problems of the prior art, a cloud-based cross-domain collaboration method and system for controlled access to global medical data are provided. The present invention aims to realize the sharing and controlled access of global medical data in a cloud environment, eliminate the data barriers between private clouds of different hospitals, and promote data interoperability and collaboration between different medical institutions, thereby reducing the need for repeated medical examinations, reducing the total data storage space, and improving overall data utilization.

[0005] In order to solve the above technical problems, the technical solution adopted by the present invention is: A cloud-based cross-domain collaboration method for controlled access to global medical data includes the following steps: S1, when node A needs to access node B’s data, it addresses node B on the blockchain; S2, node A creates a transaction request Trans_Apply based on the access attribute, uploads it to the chain and specifies node B as the recipient; S3, Node B monitors the information on the blockchain and receives the transaction request Trans_Apply as the receiver; S4, node B uses the public key of node A to decrypt the transaction request Trans_Apply to obtain access attributes; S5, Node B determines whether it meets the authorization conditions based on the access attributes. If it meets the authorization conditions, Node B generates an access token Token containing restriction information, binds the access token Token to Node A to generate a transaction confirmation Trans_Approve, uploads it to the chain and specifies Node A as the recipient, and jumps to step S6; otherwise, it ends and exits; S6, Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient, decrypts the transaction confirmation Trans_Approve using the public key of Node B to obtain the access token Token, and uses the access token Token as the credential to access the data in Node B, and sends a data access request to Node B through the specified interface; S7, after receiving the data access request, node B verifies the access token Token carried in the data access request. If the access token Token is valid, the local medical data is screened and decrypted, and node A's data access request for local data is allowed, and the process goes to step S8; otherwise, node A's data access request is rejected, and the process ends and exits; S8, node B generates consumption data Trans_Con and uploads it to the chain to deduct the fees of node A. At the same time, the smart contract is used to detect whether there is any abnormality in the data access request of node A. If there is an abnormality, the smart contract will automatically refund and deduct the fees of node A, and record the detailed information of the abnormality for audit query.

[0006] Optionally, the format of the transaction request Trans_Apply in step S2 is: Trans_Apply <ID A , ID B , DATA_TYPE, LEVEL, DETAILS, EXPIRE_DATA> s Among them, ID A is the ID of node A. B is the number of node B, DATA_TYPE is the data type requested for access, LEVEL is the permission level, DETAILS is the specific access attributes, the access attributes include access data description and access authorization information, the access data description includes at least one of data time and keyword, the access authorization information includes at least one of authorization information and privacy level information, EXPIRE_DATA is the access period; the subscript s indicates a private key signature, and the data type DATA_TYPE requested for access is plain text, or part or all of the data type DATA_TYPE requested for access is encrypted using the public key of node B to obtain ciphertext.

[0007] Optionally, the format of the transaction confirmation Trans_Approve generated in step S5 is: Trans_Approve <ID B , ID A , Token A > s Among them, ID A is the ID of node A. B is the number of node B, Token A The access token Token generated for node B containing restriction information; the subscript s indicates the private key signature.

[0008] Optionally, in step S5, node B generates an access token Token containing restriction information, wherein the access token Token includes the designated user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; in step S7, after receiving the data access request, node B verifies the access token Token carried in the data access request, including verifying whether the access token Token is correct by respectively verifying the user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; if any one of the items does not meet the detection rules, the access token Token is determined to be invalid; otherwise, the access token Token is determined to be valid.

[0009] Optionally, the format of the consumption data Trans_Con generated by node B in step S8 is: Trans_Con <ID B , ID A , prove, operate, hash, time> s , Among them, ID A is the ID of node A. B is the number of node B, prove is the access request record of node A, operate means execution operation, hash means data summary, time is timestamp; subscript s means private key signature.

[0010] Optionally, the on-chain includes nodes in the entire domain voting on the data to be on-chain in the form of blocks through an election committee, and the on-chain is executed only when the election committee votes in favor, and the generation of the election committee includes: a) The node that wishes to run for election committee member broadcasts the message APPLY, the format of which is: APPLY<ID, view, r, t> s , Where ID is the unique identification number of the node in the whole domain, view is the blockchain view stored by the current node, r is the current round, t is the timestamp; the subscript s represents the private key signature; b) After receiving the first APPLY message in this round, the node enters the election state. In this state, no blockchain consensus is performed and all APPLY messages are collected within the preset time T1; c) The node generates voting information VOTE and sends it to the corresponding candidate node. The format of voting information VOTE is: VOTE<ID, apply, YES, t> s Among them, ID represents the node ID, apply represents the node being voted, YES represents a vote in favor, t represents a timestamp, and the subscript s represents a private key signature. In the election state, the node can send an application message APPLY. d) After the election node receives more than 2 / N voting information VOTE within the preset time T2, it broadcasts the notification message Announce. The format of the notification message Announce is: Announce <ID, VoteList <vote>, t> s , Among them, ID is the node information, VoteList <vote>The VOTE tickets collected by this node, t represents the timestamp; the subscript s represents the private key signature; e) The node counts the received notification messages Announce. When the number of received notification messages Announce reaches the preset M, the node broadcasts the pre-change message PRE_Change. The format of the pre-change message PRE_Change is: PRE_Change <ID, ID_List<ID x >, AnnounceList <announce>, t> s , Among them, ID is the ID of this node, ID_List <ID x > is the node ID list of M notification messages Announce, AnnounceList <announce>The Announce list of notification messages corresponding to the ID list, t is the timestamp; the subscript s represents the private key signature; f) When a node receives the pre-change message PRE_Change, it selects the t with the earliest timestamp for confirmation; g) If more than N / 2 nodes confirm, the information on the chain is uploaded, and the ID_List contained in the information on the chain <ID x >They will become new committee members and complete the election of this round of election committee.

[0011] Optionally, allowing node A to request data access to local data after screening and decrypting the local medical data in step S7 means that node B allows node A to request a cloud desktop for local data, and provides node A with access rights to the decrypted data by setting corresponding role control and authority levels in the locally set medical information database based on the restriction information in the access token Token.

[0012] In addition, the present invention also provides a cloud-based cross-domain collaboration system for controlled access to global medical data, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the cloud-based cross-domain collaboration method for controlled access to global medical data.

[0013] In addition, the present invention also provides a computer-readable storage medium, which stores a computer program / instruction, and the computer program / instruction is programmed or configured to execute the cloud-to-cloud cross-domain collaboration method for controlled access to global medical data through a processor.

[0014] In addition, the present invention also provides a computer program product, including a computer program / instruction, which is programmed or configured to execute the cloud-based cross-domain collaboration for controlled access to global medical data through a processor.

[0015] Compared with the prior art, the present invention has the following advantages: At present, the cross-domain collaboration mode of medical data mainly adopts centralized storage, and medical institutions use the idle time of the network to transfer medical data to centralized storage, which brings great challenges to both storage capacity and carrying capacity. The present invention abandons the traditional centralized storage, based on the idea that private data does not leave the domain, solves the data heterogeneity between medical institutions through the cloud desktop method, and reduces the transmission pressure and network delay caused by large-scale data transmission, ensuring the security of private data. In order to further enhance data security, access control and behavior evidence are performed through blockchain. Only storing behavior information can reduce storage costs, improve safety factors, protect data privacy, and also provide data traceability for convenient supervision. The present invention includes three parts: data chaining, access control and remote access, aiming to realize the sharing and controlled access of medical data through the combination of cloud computing, blockchain technology and virtual cloud desktop, realize model innovation, provide data cross-domain collaboration, reduce repeated medical examinations, improve overall data utilization, reduce the total data storage space, and promote the release of medical data value. The cloud-based cross-domain collaboration method for controlled access to global medical data of the present invention includes adding medical institution nodes to the blockchain, and the nodes can access data across institutions, and all access behaviors are put on the chain to facilitate behavioral auditing; users do not need to adapt to access heterogeneous data, and can directly access through the cloud desktop, reducing data transmission and adaptation work, and ensuring that data is visible outside the domain. In order to solve the problems of heterogeneous data processing, network transmission pressure, and storage resource waste brought about by traditional centralized storage, the present invention, based on the guidance of cloud computing theory and relying on the principle of distributed accounting, designs cloud-based global medical data controlled access and cross-domain collaboration based on blockchain, uses blockchain to supervise data interaction behavior, and uses cloud desktop to solve data heterogeneity problems, which has the advantages of reducing transmission, ensuring data privacy, and behavior supervision and traceability. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 Schematic diagram of the basic flow of the method of the embodiment of the present invention.

[0017] Figure 2 This is the difference between cross-domain collaboration and centralized storage of global smart medical data in the cloud in the embodiment of the present invention.

[0018] Figure 3 This is the committee election process in the embodiment of the present invention. DETAILED DESCRIPTION

[0019] like Figure 1 As shown, the cloud-based cross-domain collaboration method for controlled access to global medical data in this embodiment includes the following steps: S1, when node A needs to access node B's data, it addresses node B on the blockchain; where node A and node B are nodes in different domains, such as different hospitals or medical institutions, and each has private data; S2, node A creates a transaction request Trans_Apply based on the access attribute, uploads it to the chain and specifies node B as the recipient; S3, Node B monitors the information on the blockchain and receives the transaction request Trans_Apply as the receiver; S4, node B uses the public key of node A to decrypt the transaction request Trans_Apply to obtain access attributes; S5, Node B determines whether it meets the authorization conditions based on the access attributes. If it meets the authorization conditions, Node B generates an access token Token containing restriction information, binds the access token Token to Node A to generate a transaction confirmation Trans_Approve, uploads it to the chain and specifies Node A as the recipient, and jumps to step S6; otherwise, it ends and exits; S6, Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient, decrypts the transaction confirmation Trans_Approve using the public key of Node B to obtain the access token Token, and uses the access token Token as the credential to access the data in Node B, and sends a data access request to Node B through the specified interface; S7, after receiving the data access request, node B verifies the access token Token carried in the data access request. If the access token Token is valid, the local medical data is screened and decrypted, and node A's data access request for local data is allowed, and the process goes to step S8; otherwise, node A's data access request is rejected, and the process ends and exits; S8, Node B generates consumption data Trans_Con and uploads it to the chain to deduct the fees of Node A. At the same time, the smart contract is used to detect whether there is any abnormality in the data access request of Node A. If there is an abnormality, the smart contract will automatically refund and deduct the fees of Node A, and record the detailed information of the abnormality for audit query. For example, the detailed information of the abnormality recorded in this embodiment includes timestamp, reason, etc., for subsequent audit and investigation. On this basis, auditors and regulators can collect and analyze the data on the chain, perform compliance checks, contract verification, compliance audits and other operations, and monitor and audit transaction records. Auditing can ensure the correct operation of the system, ensure the transparency and security of medical data transactions in the entire domain, verify the authenticity and compliance of data transactions, and ensure the healthy development of data collaboration and sharing.

[0020] The format of the transaction request Trans_Apply in step S2 of this embodiment is: Trans_Apply <ID A , ID B , DATA_TYPE, LEVEL, DETAILS, EXPIRE_DATA> s Among them, ID A is the ID of node A. B is the number of node B, DATA_TYPE is the data type requested for access, LEVEL is the permission level, DETAILS is the specific access attributes, the access attributes include access data description and access authorization information, the access data description includes at least one of data time and keyword, the access authorization information includes at least one of authorization information and privacy level information, EXPIRE_DATA is the access period; the subscript s indicates a private key signature, and the data type DATA_TYPE requested for access is plain text, or part or all of the data type DATA_TYPE requested for access is encrypted using the public key of node B to obtain ciphertext.

[0021] The format of the transaction confirmation Trans_Approve generated in step S5 of this embodiment is: Trans_Approve <ID B , ID A , Token A > s Among them, ID A is the ID of node A. B is the number of node B, Token A The access token Token generated for node B containing restriction information; the subscript s indicates the private key signature.

[0022] In step S5 of this embodiment, node B generates an access token Token containing restriction information, in which the access token Token includes the designated user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; in step S7, after receiving the data access request, node B verifies the access token Token carried in the data access request, including verifying whether the access token Token is correct by respectively verifying the user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; if any one of the items does not meet the detection rules, the access token Token is determined to be invalid; otherwise, the access token Token is determined to be valid.

[0023] The format of the consumption data Trans_Con generated by node B in step S8 of this embodiment is: Trans_Con <ID B , ID A , prove, operate, hash, time> s , Among them, ID A is the ID of node A. B is the number of node B, prove is the access request record of node A, operate means execution operation, hash means data summary, time is timestamp; subscript s means private key signature.

[0024] The cloud-based cross-domain collaboration method for controlled access to global medical data in this embodiment includes building a blockchain, remote access, and exception handling to ensure that medical imaging data is available, visible, and unreachable. Among them, local storage of medical data includes: 1.1) local storage of medical data, establishment of an index table for easy search; 1.2) setting data access rights, including role control, authority level, etc.; 1.3) regular security audits and vulnerability scans to promptly discover and repair potential security risks. Blockchain technology is used to keep traces and evidence between medical institutions across the region to ensure that all behaviors are difficult to tamper with and traceable on the chain. As a blockchain that is only open to members of a specific group, the alliance chain has high controllability and only opens data to member nodes, which can better protect the privacy and security of medical data. Therefore, medical institutions can collaborate on data by building an alliance chain.

[0025] A consortium chain needs to be built between all medical institutions in the entire domain: 2.1) Medical institutions participating in the consortium chain apply for a unique identity ID; 2.2) Create a genesis block, record the timestamp creation time, chainID block chain identifier, alloc initial participating node information, including the address address and ID information of all participating nodes, and config configuration information. 2.3) Execute the election step. The chain in this embodiment includes nodes in the entire domain voting on the data that needs to be chained in the form of blocks through an election committee, and the chain is only executed when the election committee votes in favor. Figure 3 As shown, the generation of the election committee in this embodiment includes: a) The node that wishes to run for election committee member broadcasts the message APPLY, such as Figure 3 As shown in (a) in the figure, its format is: APPLY<ID, view, r, t> s , Where ID is the unique identification number of the node in the whole domain, view is the blockchain view stored by the current node, r is the current round, t is the timestamp; the subscript s represents the private key signature; b) After receiving the first APPLY message in this round, the node enters the election state. In this state, no blockchain consensus is performed and all APPLY messages are collected within the preset time T1; c) The node generates voting information VOTE and sends it to the corresponding candidate node, such as Figure 3 As shown in (b) in the figure, the format of the voting information VOTE is: VOTE<ID, apply, YES, t> s Among them, ID represents the node ID, apply represents the node being voted, YES represents a vote in favor, t represents a timestamp, and the subscript s represents a private key signature. In the election state, the node can send an application message APPLY. d) After the election node receives more than 2 / N voting information VOTE within the preset time T2, it broadcasts the notification message Announce, such as Figure 3 As shown in (c) in the figure, the format of the notification message Announce is: Announce <ID, VoteList <vote>, t> s , Among them, ID is the node information, VoteList <vote>The VOTE tickets collected by this node, t represents the timestamp; the subscript s represents the private key signature; e) The node counts the received notification messages Announce. When the number of received notification messages Announce reaches the preset M, it broadcasts the pre-change message PRE_Change, such as Figure 3 As shown in (d) in the figure, the format of the pre-change message PRE_Change is: PRE_Change <ID, ID_List<ID x >, AnnounceList <announce>, t> s , Among them, ID is the ID of this node, ID_List <ID x > is the node ID list of M notification messages Announce, AnnounceList <announce>The Announce list of notification messages corresponding to the ID list, t is the timestamp; the subscript s represents the private key signature; f) When a node receives the pre-change message PRE_Change, it selects the earliest timestamp t for confirmation, such as Figure 3 As shown in (e); g) If more than N / 2 nodes confirm, the information on the chain is uploaded, and the ID_List contained in the information on the chain <ID x >They will become new committee members and complete the election of this round of election committee.

[0026] Through the election committee, some nodes can be designated for consensus, thereby improving consensus efficiency, accelerating on-chain, reducing information interaction between nodes, and reducing network communication requirements. When the specified time window is exceeded, the remaining nodes can initiate an application for election on their own to ensure the rotation of the committee. Based on smart contracts, election and voting rules can be designed. The contract execution process is transparent and difficult to tamper with, which effectively ensures the fairness of voting and reduces the possibility of human intervention and malicious misconduct. The elected committee members need to obtain information from more than half of the VOTEs to initiate pre-election information. When enough election nodes (≥M) obtain enough votes (>N / 2), the term change can be carried out, and the term change information will be on the chain to facilitate nodes to read the committee list. Data on the chain includes: a) After the node creates a transaction, it signs the transaction and broadcasts it to the committee members; b) After the committee members receive the message, they verify it to ensure the validity of the transaction; c) The committee member nodes reach consensus through a consensus algorithm (such as PBFT), and the transaction is packaged into a block after reaching a global consensus; d) The node can access the committee to update the block information. In this method, in order to save blockchain storage space, access pressure, etc., only the data access requests, token consumption and other information between institutions are recorded, which can monitor the collaboration between institutions.

[0027] In order to ensure that the data is available and visible but not accessible, in step S7 of this embodiment, after screening and decrypting the local medical data, allowing node A to request data access to the local data means that node B allows node A to request cloud desktop for local data, and provides node A with access rights to the decrypted data by setting corresponding role control and permission levels in the locally set medical information database based on the restriction information in the access token Token. Through cloud desktop access, B builds a local virtual machine to read local data, and provides A with remote access function according to the Token permission level, which reduces the network pressure and delay caused by large data transmission, and solves the problem of inconsistent data structure between A and B. Data collaboration between institutions requires access application, verification authorization and data access, which are initiated by the institution. For example, if a patient in Hospital A wants to query his historical data in Hospital B, he can grant his own authority to Hospital A, and Hospital A applies to Hospital B for access to the patient's previous medical data; after Hospital B verifies the access application, it grants the patient's data access right Token to Hospital A; Hospital A can access the data of Hospital B according to the access interface published on the chain of Hospital B; after Hospital B verifies the access right, it provides remote desktop access to A after screening and decrypting the data. Figure 2 As shown in the left sub-figure (a), the traditional method is to store and access all medical data in a centralized manner. This method of uploading all data puts great pressure on storage and transportation. Figure 2 As shown in the right sub-figure (b), in this embodiment, local storage of medical data is adopted, which reduces the risk of data out of the domain and the accompanying network transmission pressure and centralized storage pressure; remote desktop technology can not only solve the problem of data heterogeneity in medical institutions, but also ensure that data is visible and not accessible, and fully ensure the security of medical privacy data; different data can be accessed according to different permissions, such as when academic research and statistical data, the patient's privacy information can be blurred; when querying patient medical information, other patients' medical records cannot be accessed, etc.

[0028] In summary, the cloud-based cross-domain collaboration method of this embodiment includes a data storage and controlled access method, and the original medical data is stored in the private cloud of each hospital; when a user applies for access to the original data at any blockchain node, his identity is authenticated to determine whether he has access rights to the original data; users with permissions can apply to access the original data, and the original data is displayed to cross-domain users in the form of a remote desktop, ensuring that the data is visible and unavailable while realizing the function of reading data in a different place; at the same time, the behavior of data access is recorded in the blockchain. The cloud-based cross-domain collaboration method of this embodiment can realize the sharing of global medical data in the cloud environment, realize controlled access to heterogeneous diagnosis and treatment data stored in different places, reduce repeated medical examinations, improve overall data utilization, reduce the total data storage space, and promote the release of medical data value. The core goal of the cloud-based cross-domain collaboration method of this embodiment is to realize the sharing and controlled access of global medical data in the cloud environment, eliminate the data barriers between private clouds of different hospitals, promote data intercommunication and collaboration between different medical institutions, thereby reducing the need for repeated medical examinations, reducing the total data storage space, and improving the overall data utilization. This not only helps to reduce the storage pressure of medical institutions, but also effectively promotes the release and utilization of medical data value. Through cloud-based distributed accounting technology, the transparency and verifiability of medical data transactions can be audited and supervised. In this embodiment, each access record of the cloud-based cross-domain collaboration method data will be recorded on the blockchain, forming a historical record that is not easy to tamper with. This can not only ensure the integrity and authenticity of the data, but also provide effective supervision means for national controlled agencies to ensure the security and compliance of medical data.

[0029] In addition, this embodiment also provides a cloud-based cross-domain collaboration system for controlled access to global medical data, including an interconnected microprocessor and a memory, wherein the microprocessor is programmed or configured to execute the cloud-based cross-domain collaboration method for controlled access to global medical data.

[0030] In addition, this embodiment also provides a computer-readable storage medium, which stores a computer program / instruction, and the computer program / instruction is programmed or configured to execute the cloud-to-cloud cross-domain collaboration method for controlled access to global medical data through a processor.

[0031] In addition, this embodiment also provides a computer program product, including a computer program / instruction, which is programmed or configured to execute the cloud-to-cloud cross-domain collaboration method for controlled access to global medical data through a processor.

[0032] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present application can take the form of a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the process Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific way, so that the instructions stored in the computer-readable memory produce a product including an instruction device, which implements the functions specified in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operation steps are executed on the computer or other programmable device to produce a computer-implemented process, so that the instructions executed on the computer or other programmable device provide for implementing the process in the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0033] The above is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should also be regarded as the protection scope of the present invention.< / announce> < / announce> < / vote> < / vote> < / announce> < / announce> < / vote> < / vote>

Claims

1. A cloud-based cross-domain collaboration method for controlled access to global medical data, characterized in that: The steps include: S1, when node A needs to access node B’s data, it addresses node B on the blockchain; S2, node A creates a transaction request Trans_Apply based on the access attribute, uploads it to the chain and specifies node B as the recipient; S3, Node B monitors the information on the blockchain and receives the transaction request Trans_Apply as the receiver; S4, node B uses the public key of node A to decrypt the transaction request Trans_Apply to obtain access attributes; S5, Node B determines whether it meets the authorization conditions based on the access attributes. If it meets the authorization conditions, Node B generates an access token Token containing restriction information, binds the access token Token to Node A to generate a transaction confirmation Trans_Approve, uploads it to the chain and specifies Node A as the recipient, and jumps to step S6; otherwise, it ends and exits; S6, Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient, decrypts the transaction confirmation Trans_Approve using the public key of Node B to obtain the access token Token, and uses the access token Token as the credential to access the data in Node B, and sends a data access request to Node B through the specified interface; S7, after receiving the data access request, node B verifies the access token Token carried in the data access request. If the access token Token is valid, the local medical data is screened and decrypted, and node A's data access request for local data is allowed, and the process goes to step S8; otherwise, node A's data access request is rejected, and the process ends and exits; S8, node B generates consumption data Trans_Con and uploads it to the chain to deduct the fees of node A. At the same time, the smart contract is used to detect whether there is any abnormality in the data access request of node A. If there is an abnormality, the smart contract will automatically refund and deduct the fees of node A, and record the detailed information of the abnormality for audit query.

2. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 1, characterized in that: The format of the transaction request Trans_Apply in step S2 is: Trans_Apply<ID A , ID B , DATA_TYPE, LEVEL, DETAILS, EXPIRE_DATA> s Among them, ID A is the ID of node A. B is the number of node B, DATA_TYPE is the data type requested for access, LEVEL is the permission level, DETAILS is the specific access attributes, the access attributes include access data description and access authorization information, the access data description includes at least one of data time and keyword, the access authorization information includes at least one of authorization information and privacy level information, EXPIRE_DATA is the access period; the subscript s indicates a private key signature, and the data type DATA_TYPE requested for access is plain text, or part or all of the data type DATA_TYPE requested for access is encrypted using the public key of node B to obtain ciphertext.

3. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 1, characterized in that: The format of the transaction confirmation Trans_Approve generated in step S5 is: Trans_Approve<ID B , ID A , Token A > s Among them, ID A is the ID of node A. B is the number of node B, Token A The access token Token generated for node B containing restriction information; the subscript s indicates the private key signature.

4. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 3 is characterized in that: In step S5, node B generates an access token Token containing restriction information, wherein the access token Token includes the designated user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; in step S7, after receiving the data access request, node B verifies the access token Token carried in the data access request, including verifying whether the access token Token is correct by respectively verifying the user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA. If any one of the items does not meet the detection rules, the access token Token is determined to be invalid; otherwise, the access token Token is determined to be valid.

5. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 3 is characterized in that: The format of the consumption data Trans_Con generated by node B in step S8 is: Trans_Con<ID B , ID A , prove, operate, hash, time> s , Among them, ID A is the ID of node A. B is the number of node B, prove is the access request record of node A, operate means execution operation, hash means data summary, time is timestamp; subscript s means private key signature.

6. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 1 is characterized in that: The on-chain includes nodes in the entire domain voting on the data that needs to be on-chain in the form of blocks through the election committee. The on-chain is executed only when the election committee votes in favor, and the generation of the election committee includes: a) The node that wishes to run for election committee member broadcasts the message APPLY, the format of which is: APPLY<ID, view, r, t> s , Where ID is the unique identification number of the node in the whole domain, view is the blockchain view stored by the current node, r is the current round, t is the timestamp; the subscript s represents the private key signature; b) After receiving the first APPLY message in this round, the node enters the election state. In this state, no blockchain consensus is performed and all APPLY messages are collected within the preset time T1; c) The node generates voting information VOTE and sends it to the corresponding candidate node. The format of voting information VOTE is: VOTE<ID, apply, YES, t> s Among them, ID represents the node ID, apply represents the node being voted, YES represents a vote in favor, t represents a timestamp, and the subscript s represents a private key signature. In the election state, the node can send an application message APPLY. d) After the election node receives more than 2 / N voting information VOTE within the preset time T2, it broadcasts the notification message Announce. The format of the notification message Announce is: Announce<ID, VoteList <vote> , t> s ，< / vote> Among them, ID is the node information, VoteList <vote> The VOTE tickets collected by this node, t represents the timestamp; the subscript s represents the private key signature;< / vote> e) The node counts the received notification messages Announce. When the number of received notification messages Announce reaches the preset M, the node broadcasts the pre-change message PRE_Change. The format of the pre-change message PRE_Change is: PRE_Change<ID, ID_List<ID x >, AnnounceList <announce> , t> s ，< / announce> Among them, ID is the ID of this node, ID_List <ID x > is the node ID list of M notification messages Announce, AnnounceList <announce> The Announce list of notification messages corresponding to the ID list, t is the timestamp; the subscript s represents the private key signature;< / announce> f) When a node receives the pre-change message PRE_Change, it selects the t with the earliest timestamp for confirmation; g) If more than N / 2 nodes confirm, the information on the chain is uploaded, and the ID_List contained in the information on the chain <ID x >They will become new committee members and complete the election of this round of election committee.

7. The cloud-based cross-domain collaboration method for controlled access to global medical data according to claim 1 is characterized in that: Allowing node A to request data access to local data after screening and decrypting the local medical data in step S7 means that node B allows node A to request a cloud desktop for local data, and provides node A with access rights to the decrypted data by setting corresponding role control and authority levels in the locally set medical information database based on the restriction information in the access token Token.

8. A cloud-based cross-domain collaboration system for controlled access to global medical data, comprising interconnected microprocessors and memories, characterized in that: The microprocessor is programmed or configured to execute the cloud-based cross-domain collaboration method for controlled access to global medical data as described in any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program / instruction stored therein, characterized in that: The computer program / instruction is programmed or configured to execute, through a processor, the cloud-based cross-domain collaboration method for controlled access to global medical data as described in any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that The computer program / instruction is programmed or configured to execute, through a processor, the cloud-based cross-domain collaboration method for controlled access to global medical data as described in any one of claims 1 to 7.

Images