Inter-cloud cross-domain collaboration method and system for global medical data controlled access

Abstract

The application discloses a kind of global medical data controlled access-oriented inter-cloud cross-domain cooperation method and system, the method of the present application includes that node A creates transaction request according to access attribute, chain and specify node B as receiver;Then node B generates access token containing restriction information, binds access token node A generates transaction confirmation, chain and specify node A as receiver;Node A and access token are used as the voucher of data in node B, and send data access request to node B through specified interface;Node B verifies the access token carried in data access request and controls whether to allow data access request.The present application aims to realize the sharing and controlled access of global medical data in inter-cloud environment, eliminate the data barrier between different hospital private clouds, promote data intercommunication and cooperation between different medical institutions, thereby reduce the need for repeated medical examination, reduce the total data storage space while improving overall data utilization.

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 advancement of information technology, the digitalization and intelligentization of hospitals is becoming an increasingly important trend in the healthcare industry. However, as technology continues to evolve, the amount of data generated by medical institutions is growing exponentially, with both the variety and volume of data increasing. Global healthcare data already amounts to hundreds of exabytes and is growing at an accelerating rate. A large tertiary hospital in China performs up to 410,000 radiology and ultrasound examinations annually, with the size of individual medical images increasing from 250MB to nearly 800MB. Pathology data files range in size from hundreds of MB to several GB. Hospital storage capacity has exploded over the past four years, from tens of terabytes to hundreds of terabytes. However, according to relevant laws and regulations, hospitals must retain outpatient medical records for at least 15 years and inpatient records for at least 30 years, placing significant demands on medical institutions' storage capacity. Furthermore, due to the existence of information silos within hospitals, medical data is difficult to share and interoperate, inevitably leading to patients seeking duplicate medical examinations across different hospitals, resulting in longer wait times and higher medical expenses. This also results in a waste of public medical resources and duplicated spending 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] Currently, due to regional policy requirements, medical data must be uploaded to a nationally controlled institution for centralized storage. This approach not only doubles the storage capacity but also poses significant challenges to data transport. Due to the varying structured and unstructured data storage architectures across hospitals, even centralized data storage still creates barriers. Cross-domain controlled access to medical data on private clouds across different hospitals, particularly cross-hospital sharing of medical imaging data, is extremely challenging. Therefore, achieving cross-domain controlled access to medical data requires addressing the heterogeneity of medical data, controlled access, and the transmission of large amounts of data. The varying storage formats of data across private clouds create difficult-to-break barriers between clouds. The complex identities of individuals from different institutions and the frequent movement of patients across multiple institutions create a significant need for identity-based access control due to the sensitivity and privacy of medical data. Medical data, especially imaging data, is enormous, and cross-hospital access requires significant data transfer. A single CT scan can generate hundreds to thousands of images, with a single transfer size potentially reaching several gigabytes. For example, with a 5G network and 100M bandwidth, image transmission latency is approximately 400 seconds. Addressing this latency in large data transmission is a pressing issue. Summary of the Invention

[0004] Technical problem to be solved by the present invention: In response to 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:

[0006] A cloud-to-cloud cross-domain collaboration method for controlled access to global medical data includes the following steps:

[0007] S1, when node A needs to access node B’s data, it addresses node B on the blockchain;

[0008] S2, node A creates a transaction request Trans_Apply based on the access attributes, uploads it to the chain, and specifies node B as the recipient;

[0009] S3, Node B monitors the information on the blockchain and receives the transaction request Trans_Apply as the receiver;

[0010] S4, node B uses node A's public key to decrypt the transaction request Trans_Apply to obtain access attributes;

[0011] In step S5, node B determines whether the authorization conditions are met based on the access attributes. If so, node B generates an access token Token containing restriction information, binds the access token Token to node A, generates a transaction confirmation Trans_Approve, uploads it to the chain, and specifies node A as the recipient, then jumps to step S6; otherwise, the process ends and exits.

[0012] S6: Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient. It uses the public key of node B to decrypt the transaction confirmation Trans_Approve to obtain the access token Token. It then 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.

[0013] 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, Node B filters and decrypts the local medical data and allows Node A's data access request for the local data, and jumps to step S8; otherwise, Node A's data access request is rejected, and the process ends and exits.

[0014] In 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 an abnormality occurs, the smart contract will automatically refund and deduct the fees of node A, and record the detailed information of the abnormality for audit query.

[0015] Optionally, the format of the transaction request Trans_Apply in step S2 is:

[0016] Trans_Apply <ID A , ID B , DATA_TYPE, LEVEL, DETAILS, EXPIRE_DATA> s

[0017] Among them, ID A is the number of node A, ID 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 expiration date; 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.

[0018] Optionally, the format of the transaction confirmation Trans_Approve generated in step S5 is:

[0019] Trans_Approve <ID B , ID A , Token A > s

[0020] Among them, ID A is the number of node A, ID B Token is the number of node B. A The access token Token generated for node B contains restriction information; the subscript s indicates the private key signature.

[0021] Optionally, the access token Token in step S5 includes the restriction information, and the access token Token includes the user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA; in step S7, the node B verifies the access token Token carried in the data access request after receiving the data access request, and the access token Token is verified to be correct by using the user A, the expiration date EXPIRE_DATA, the authorization level LEVEL and the access data DATA respectively, if any one does not meet the detection rule, it is determined that the access token Token is invalid, otherwise it is determined that the access token Token is valid.

[0022] Optionally, the format of the consumption data Trans_Con generated by the node B in step S8 is as follows:

[0023] Trans_Con<ID B , ID A , prove, operate, hash, time> s ,

[0024] wherein ID A is the number of node A, ID B is the number of node B, prove is the access record of node A, operate indicates the execution operation, hash indicates the data digest, and time is the time stamp; the subscript s indicates the private key signature.

[0025] Optionally, the upper chain includes that the nodes in the universe vote for the consensus of the data which needs to be chained in the form of block through the election committee, and the upper chain is executed only when the election committee votes through, and the generation of the election committee includes:

[0026] a) the node which hopes to be elected as a member of the election committee broadcasts an application message APPLY, and the format of the application message APPLY is as follows:

[0027] APPLY<ID, view, r, t> s ,

[0028] wherein ID is the unique identification number of the node in the universe, view is the block chain view stored by the current node, r is the current round, and t is the time stamp; the subscript s indicates the private key signature;

[0029] b) the node enters an election state after receiving the first application message APPLY in the current round, and the state does not perform block chain consensus, and all application messages APPLY are collected within the preset time T1.

[0030] c) The node generates voting information VOTE and sends it to the corresponding candidate node, the format of the voting information VOTE is:

[0031] VOTE<ID, apply, YES, t> s

[0032] Wherein, ID represents the node ID, apply is the node to be voted, YES represents to vote for, t represents the time stamp; subscript s represents the private key signature; and the node can send the application message APPLY in the election state;

[0033] d) The candidate node receives more than 2 / N voting information VOTE within a preset time T2, and broadcasts a notification message Announce, the format of the notification message Announce is:

[0034] Announce<ID, VoteList <vote>, t> s ,

[0035] Among them, ID is node information, VoteList <vote>The VOTE tickets collected by this node, t represents the timestamp; the subscript s represents the private key signature;

[0036] e) The node counts the received Announce messages. When the number of received Announce messages reaches the preset M, it broadcasts a pre-change message PRE_Change. The format of the pre-change message PRE_Change is:

[0037] PRE_Change <ID, ID_List<ID x >, AnnounceList <announce>, t> s ,

[0038] Among them, ID is the ID of this node, ID_List <ID x > AnnounceList is the node ID list of M notification messages Announce <announce>Announce list of notification messages corresponding to the ID list, t is the timestamp; the subscript s represents the private key signature;

[0039] f) When a node receives the pre-change message PRE_Change, it selects the one with the earliest timestamp t for confirmation;

[0040] g) If more than N / 2 nodes confirm, the information on the chain will be uploaded, and the ID_List included in the information on the chain <ID x >They will become new committee members, completing the election of this round of election committee.

[0041] Optionally, allowing node A to request data access to local data after filtering 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 permission levels in the locally set medical information database based on the restriction information in the access token Token.

[0042] 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.

[0043] 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.

[0044] 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-to-cloud cross-domain collaboration for controlled access to global medical data through a processor.

[0045] Compared with existing technologies, the present invention has the following major advantages: Currently, cross-domain collaboration for medical data primarily relies on centralized storage, with medical institutions using idle network time to transfer medical data to centralized storage, which poses significant challenges to both storage and transport capacity. This present invention abandons traditional centralized storage and, based on the principle that private data should remain within the domain, addresses data heterogeneity between medical institutions through a cloud desktop approach. This reduces the transmission pressure and network latency caused by large amounts of data transmission, ensuring the security of private data. To further enhance data security, access control and behavioral evidence storage are implemented through blockchain. Storing only behavioral information reduces storage costs, improves security, and protects data privacy, while also providing data traceability for easier supervision. The present invention encompasses three key areas: data on-chain, access control, and remote access. Through the combination of cloud computing, blockchain technology, and virtual cloud desktops, this invention aims to achieve shared and controlled access to medical data, achieve model innovation, provide cross-domain data collaboration, reduce duplicate medical examinations, improve overall data utilization, reduce total data storage space, and promote the release of medical data value. The present invention's cloud-based cross-domain collaboration method for controlled access to global medical data includes the following steps: medical institution nodes are added to the blockchain, nodes can access data across institutions, and all access behaviors are uploaded to the blockchain for easy behavior auditing; users do not need to adapt to access heterogeneous data, and can access directly through the cloud desktop, reducing data transmission and adaptation work, and ensuring that data is visible outside the domain. To address the problems of heterogeneous data processing, network transmission pressure, and storage resource waste brought about by traditional centralized storage, the present invention, guided by 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 behaviors, and uses cloud desktops to solve data heterogeneity problems, with the advantages of reducing transmission, ensuring data privacy, and enabling behavior supervision and traceability. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 Schematic diagram of the basic process of the method of the embodiment of the present invention.

[0047] 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.

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

[0049] like Figure 1 As shown, the cloud-to-cloud cross-domain collaboration method for controlled access to global medical data in this embodiment includes the following steps:

[0050] S1: Node A addresses Node B on the blockchain when it needs to access Node B’s data; Node A and Node B are nodes in different domains, such as different hospitals or medical institutions, and each has private data;

[0051] S2, node A creates a transaction request Trans_Apply based on the access attributes, uploads it to the chain, and specifies node B as the recipient;

[0052] S3, Node B monitors the information on the blockchain and receives the transaction request Trans_Apply as the receiver;

[0053] S4, node B uses node A's public key to decrypt the transaction request Trans_Apply to obtain access attributes;

[0054] In step S5, node B determines whether the authorization conditions are met based on the access attributes. If so, node B generates an access token Token containing restriction information, binds the access token Token to node A, generates a transaction confirmation Trans_Approve, uploads it to the chain, and specifies node A as the recipient, then jumps to step S6; otherwise, the process ends and exits.

[0055] S6: Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient. It uses the public key of node B to decrypt the transaction confirmation Trans_Approve to obtain the access token Token. It then 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.

[0056] 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, Node B filters and decrypts the local medical data and allows Node A's data access request for the local data, and jumps to step S8; otherwise, Node A's data access request is rejected, and the process ends and exits.

[0057] 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 Node A's data access request. If an abnormality occurs, 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, cause, etc., for subsequent audit and investigation. On this basis, auditors and regulators can collect and analyze the data on the chain, conduct compliance checks, contract verification, compliance audits and other operations, and monitor and audit transaction records. Audits can ensure the correct operation of the system, guarantee the transparency and security of medical data transactions across the entire domain, verify the authenticity and compliance of data transactions, and ensure the healthy development of data collaboration and sharing.

[0058] The format of the transaction request Trans_Apply in step S2 of this embodiment is:

[0059] Trans_Apply <ID A , ID B , DATA_TYPE, LEVEL, DETAILS, EXPIRE_DATA> s

[0060] Among them, ID A is the number of node A, ID 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 expiration date; 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.

[0061] The format of the transaction confirmation Trans_Approve generated in step S5 of this embodiment is:

[0062] Trans_Approve <ID B , ID A , Token A > s

[0063] Among them, ID A is the number of node A, ID B Token is the number of node B. A The access token Token generated for node B contains restriction information; the subscript s indicates the private key signature.

[0064] The node B generates the access token Token containing the restriction information in step S5 of the embodiment. The access token Token includes the specified user A, the use limit EXPIRE_DATA, the authorization level LEVEL and the access data DATA. In step S7, the node B verifies the access token Token carried in the data access request after receiving the data access request. The verification includes verifying whether the access token Token is correct by using the user A, the use limit EXPIRE_DATA, the authorization level LEVEL and the access data DATA respectively. If any of them does not conform to the detection rule, it is determined that the access token Token is invalid. Otherwise, it is determined that the access token Token is valid.

[0065] The format of the consumption data Trans_Con generated by the node B in step S8 of the embodiment is as follows:

[0066] Trans_Con B , ID A , prove, operate, hash, time> s ,

[0067] ID A is the number of node A, ID B is the number of node B, prove is the access record of node A, operate indicates the execution operation, hash indicates the data digest, and time is the time stamp. The subscript s indicates the private key signature.

[0068] The cloud inter-domain collaboration method for global medical data controlled access of the embodiment includes constructing a block chain, remote access and exception handling, and ensures that the medical image data is available, visible and unavailable. Among them, the medical data is stored locally, including: 1.1) medical data local storage, index table is established to facilitate searching; 1.2) setting data access permissions, including role control, permission level, etc.; 1.3) regular security audit and vulnerability scanning, timely discovery and repair of potential security risks. All medical institutions in the world leave marks and store evidence through blockchain technology to ensure that all behaviors are difficult to tamper with and traceable. As a kind of blockchain only open to specific group members, the alliance chain has high controllability, and only member nodes can open data, which can better protect the privacy and security of medical data. Therefore, medical institutions can collaborate through the construction of alliance chain.

[0069] 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 the nodes in the entire domain voting on the data that needs to be chained in the form of blocks through the election committee. 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:

[0070] 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:

[0071] APPLY<ID, view, r, t> s ,

[0072] Where ID is the unique identification number of the node in the entire 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;

[0073] 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.

[0074] c) The node generates voting information VOTE and sends it to the corresponding candidate node, such as Figure 3 As shown in (b), the format of voting information VOTE is:

[0075] VOTE<ID, apply, YES, t> s

[0076] Where ID represents the node ID, apply represents the node being voted for, YES represents a vote in favor, t represents a timestamp, and the subscript s represents a private key signature. In the election state, a node can send an application message APPLY.

[0077] d) After the election node receives more than 2 / N votes 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:

[0078] Announce <ID, VoteList <vote>, t> s ,

[0079] Among them, ID is node information, VoteList <vote>The VOTE tickets collected by this node, t represents the timestamp; the subscript s represents the private key signature;

[0080] 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:

[0081] PRE_Change <ID, ID_List<ID x >, AnnounceList <announce>, t> s ,

[0082] Among them, ID is the ID of this node, ID_List <ID x > AnnounceList is the node ID list of M notification messages Announce <announce>Announce list of notification messages corresponding to the ID list, t is the timestamp; the subscript s represents the private key signature;

[0083] 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);

[0084] g) If more than N / 2 nodes confirm, the information on the chain will be uploaded, and the ID_List included in the information on the chain <ID x >They will become new committee members, completing the election of this round of election committee.

[0085] The election committee can designate a subset of nodes for consensus, improving consensus efficiency, accelerating on-chain transactions, reducing inter-node information exchange, and lowering network communication requirements. When a designated time window expires, the remaining nodes can initiate their own candidacy applications to ensure committee rotation. Smart contracts allow for the design of election and voting rules, making the contract execution transparent and tamper-resistant, effectively ensuring voting fairness and reducing the potential for human intervention and malicious manipulation. Elected committee members must secure at least half of the votes to initiate a pre-election. When a sufficient number of candidate nodes (≥M) secure a sufficient number of votes (>N / 2), a change of committee can take place, and this change of committee information is uploaded to the chain, making it easier for nodes to access the committee roster. Data on-chain upload involves: a) nodes creating transactions, signing them, and broadcasting them to committee members; b) committee members verifying the transaction upon receipt to ensure its validity; c) committee member nodes reach consensus through a consensus algorithm (such as PBFT), and upon reaching global consensus, the transaction is packaged into a block; d) nodes can access the committee's updated block information. In this method, in order to save blockchain storage space and access pressure, only the data access requests and token consumption between institutions are recorded, which can monitor the collaboration between institutions.

[0086] In order to ensure that the data is available and visible but not accessible, in step S7 of this embodiment, after filtering 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 a cloud desktop for the 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. Access is performed through the cloud desktop. B builds a local virtual machine to read local data and provides A with remote access functions based on the Token permission level, which reduces the network pressure and latency caused by large data transmission and solves the problem of inconsistent data structures that may exist 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 will apply 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 permission 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 verifying the access permission, Hospital B provides remote desktop access to A after filtering 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 full upload method 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 leaving the domain and the accompanying pressure on network transmission and centralized storage. Remote desktop technology can not only solve the problem of data heterogeneity in medical institutions, but also ensure that data is visible and not inaccessible, fully ensuring the security of medical privacy data. Different data can be accessed according to different permissions. For example, when academic research and statistical data are used, the patient's privacy information can be blurred. When querying patient medical information, other patients' medical records cannot be accessed.

[0087] In summary, the inter-cloud cross-domain collaboration method of the embodiment includes a data storage and controlled access method, and original medical data is stored in a private cloud of each hospital. When a user applies for access to original data at any blockchain node, the identity of the user is identified, and whether the user has access rights to the original data. A user with access rights can apply for access to the original data. The original data is presented to the cross-domain user in the form of a remote desktop, ensuring that the data is visible and not available while realizing the function of reading data remotely. At the same time, the behavior of data access is recorded in the blockchain. The inter-cloud cross-domain collaboration method can realize the sharing of global medical data in the inter-cloud environment, realize the controlled access of heterogeneous diagnosis and treatment data stored remotely, reduce medical repeated examination, improve the overall data utilization rate, reduce the total data storage space, and promote the release of medical data value. The core goal of the inter-cloud cross-domain collaboration method is to realize the sharing and controlled access of global medical data in the inter-cloud environment, eliminate the data barriers between different hospital private clouds, and promote data interconnection and collaboration between different medical institutions, thereby reducing the need for repeated medical examination, reducing the total data storage space, and improving the overall data utilization rate. 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 the inter-cloud distributed accounting technology, the transparency and verifiability of auditing and supervising medical data transactions are realized. Each access record of the data of the inter-cloud cross-domain collaboration method is recorded on the blockchain to form a history record that is not easy to tamper with. This not only ensures the integrity and authenticity of the data, but also provides effective supervision means for state-controlled agencies to ensure the safety and compliance of medical data.

[0088] In addition, the embodiment also provides an inter-cloud cross-domain collaboration system for global medical data controlled access, which comprises a microprocessor and a memory connected to each other. The microprocessor is programmed or configured to execute the inter-cloud cross-domain collaboration method for global medical data controlled access.

[0089] In addition, the embodiment also provides a computer readable storage medium, which stores computer programs / instructions programmed or configured to execute the inter-cloud cross-domain collaboration method for global medical data controlled access by a processor.

[0090] In addition, the embodiment also provides a computer program product, which comprises computer programs / instructions programmed or configured to execute the inter-cloud cross-domain collaboration method for global medical data controlled access by a processor.

[0091] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present application may 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 processes and / or boxes in the flowchart and / or block diagram, may be implemented by computer program instructions. These computer program instructions may 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 instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the functions described 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 the instruction device, which implements the function 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, thereby providing instructions for implementing the process in the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0092] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiment. All technical solutions based on the concept of the present invention are within the scope of protection of the present invention. It should be noted that for those skilled in the art, various improvements and modifications that do not depart from the principles of the present invention should also be considered within the scope of protection of the present invention.< / announce> < / announce> < / vote> < / vote> < / announce> < / announce> < / vote> < / vote>

Claims

1. A cloud-to-cloud cross-domain collaboration method for controlled access to global medical data, characterized by: 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 attributes, 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 node A's public key to decrypt the transaction request Trans_Apply to obtain access attributes; In step S5, node B determines whether the authorization conditions are met based on the access attributes. If so, node B generates an access token Token containing restriction information, binds the access token Token to node A, generates a transaction confirmation Trans_Approve, uploads it to the chain, and specifies node A as the recipient, then jumps to step S6; otherwise, the process ends and exits. S6: Node A monitors the information on the blockchain and receives the transaction confirmation Trans_Approve as the recipient. It uses the public key of node B to decrypt the transaction confirmation Trans_Approve to obtain the access token Token. It then 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, Node B filters and decrypts the local medical data and allows Node A's data access request for the local data, and jumps to step S8; otherwise, Node A's data access request is rejected, and the process ends and exits. In 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 an abnormality occurs, 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-to-cloud 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 number of node A, ID 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 expiration date; 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-to-cloud 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 number of node A, ID B Token is the number of node B. A The access token Token generated for node B contains restriction information; the subscript s indicates the private key signature.

4. The cloud-to-cloud 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, in which the access token Token includes the designated user A, the usage period 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 usage period 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-to-cloud 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 number of node A, ID B is the number of node B, prove is the access request record of node A, operate indicates the execution of the operation, hash indicates the data summary, time is the timestamp; the subscript s indicates the private key signature.

6. The cloud-to-cloud cross-domain collaboration method for controlled access to global medical data according to claim 1 is characterized in that: The on-chain process involves nodes in the entire domain voting on consensus on the data that needs to be on-chain in the form of blocks through an election committee. The data is only on-chain when the election committee votes in favor. The generation of the election committee includes: a) Nodes wishing to run for election committee members broadcast an APPLY message, the format of which is: APPLY<ID, view, r, t> s , Where ID is the unique identification number of the node in the entire 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 Where ID represents the node ID, apply represents the node being voted for, YES represents a vote in favor, t represents a timestamp, and the subscript s represents a private key signature. In the election state, a node can send an application message APPLY. d) After receiving more than 2 / N votes within the preset time T2, the election node broadcasts the notification message Announce. The format of the notification message Announce is: Announce<ID, VoteList <vote> , t> s ，< / vote> Among them, ID is 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 Announce messages. When the number of received Announce messages reaches the preset M, it broadcasts a 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 > AnnounceList is the node ID list of M notification messages Announce <announce> 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 one with the earliest timestamp t for confirmation; g) If more than N / 2 nodes confirm, the information on the chain will be uploaded, and the ID_List included in the information on the chain <ID x >They will become new committee members, completing the election of this round of election committee.

7. The cloud-to-cloud 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 filtering and decrypting the local medical data in step S7 means that node B allows node A to request cloud desktop access to 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.

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-to-cloud 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 the cloud-to-cloud cross-domain collaboration method for controlled access to global medical data as described in any one of claims 1 to 7 through a processor.

10. A computer program product comprising a computer program / instructions, characterized in that 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 as described in any one of claims 1 to 7 through a processor.

Images