An Encryption Method for Secure Cross-Institutional Sharing of Medical Case Data

Abstract

This invention relates to the field of digital information security, specifically to an encryption method for secure cross-institutional sharing of medical case data. The specific implementation steps include: acquiring a data access request and the target medical data; dynamically constructing an access verification path based on the request content and a preset graph model rule base; after completing path verification, generating an auditable verification path hash chain; digitally signing the hash chain and generating a one-time key to encrypt the medical data; encapsulating the one-time key using encryption strategies including standard strategies, EKU attribute strategies, or double-nested strategies according to the data sensitivity level; and finally encapsulating the authorization credential, encrypted data, and key encapsulation result together into a unified secure data packet. This invention significantly improves the security, traceability, and adaptability to complex scenarios of the data sharing process by cryptographically binding dynamic, auditable authorization process credentials with encrypted data.

Description

Technical Field

[0001] This invention relates to the field of digital information security, specifically to an encryption method for secure cross-institutional sharing of medical case data. Background Technology

[0002] Currently, with the continuous improvement of medical informatization in my country, more and more different types of medical institutions need to exchange information in various forms. Against this backdrop, a large number of important resources, such as electronic medical records of patients, generated by various business information systems, face a greater demand for circulation and interaction. However, existing solutions inevitably create "data silos" between the parties exchanging information, severely hindering the effective use of critical data in clinical diagnosis and treatment. Furthermore, medical data is highly valuable and sensitive; therefore, for any medical institution, the leakage of its stored important medical data would have extremely serious consequences.

[0003] To achieve cross-institutional exchange of medical data, existing technologies typically employ client / server (C / S) and browser / server (B / S) architectures, using dedicated lines, VPNs, or TLS-based API interfaces for point-to-point data transmission. However, these existing solutions still have shortcomings in terms of communication protocols and data exchange mechanisms. Due to the lack of unified technical standards and data exchange protocols, data formats are incompatible between different systems, making direct sharing difficult. Security mechanisms are separated from data payloads; protocols only guarantee the security of the transmission channel, and data packets lose direct protection after leaving the channel, their security entirely dependent on the security capabilities of the receiving system. Furthermore, the authorization mechanisms of these protocols are coarse-grained, typically unable to dynamically adjust security service levels based on the risk level of a specific data payload in a single request.

[0004] In summary, the core technical problem that urgently needs to be solved in the existing technology is the lack of a technical mechanism that can strongly bind a dynamic, trustworthy, and auditable access authorization process to the encrypted data itself at the cryptographic level. Existing solutions cannot generate a self-contained, self-proving, and self-protecting secure data unit, so that the access legitimacy of this data unit can still be independently verified and its content security can still be guaranteed after it is removed from a specific system and channel.

[0005] To address these issues, this invention proposes a cross-institutional secure sharing encryption method for medical case data. Summary of the Invention

[0006] The purpose of this invention is to provide a secure encryption method for cross-institutional sharing of medical case data to solve the problems mentioned in the background art.

[0007] To achieve the above objectives, the present invention provides the following technical solution:

[0008] A method for securely sharing medical case data across institutions using encryption, the method comprising:

[0009] Obtain data access requests and target medical data that include the target data identifier, the requester's digital certificate, access permission level, sensitivity level, and authorization status;

[0010] Based on preset verification dependencies, access verification paths are dynamically constructed for data access requests;

[0011] Access control verification is performed based on the access verification path, and the verification digest of each path node is recorded to form a verification path hash chain; if the access verification path is approved, the subsequent steps are executed.

[0012] A one-time symmetric encryption key is generated to encrypt the target medical data, resulting in encrypted data content. The verification path hash chain is then digitally signed to generate verification signature information.

[0013] Based on the sensitivity level, the target encryption strategy is dynamically determined; according to the target encryption strategy, the one-time symmetric encryption key is asymmetricly encrypted to generate a key encapsulation result;

[0014] The verification path hash chain, verification signature information, encrypted data content, and key encapsulation results are structurally encapsulated to generate a unified security data packet.

[0015] Preferably, the process of dynamically constructing an access verification path for data access requests based on preset verification dependencies is as follows:

[0016] A verification request graph model is defined, consisting of nodes and directed edges connecting the nodes. The nodes are divided into core verification nodes and auxiliary verification nodes. Core verification nodes form the basis for each access verification and include data sensitivity verification nodes, institutional trust verification nodes, and patient dynamic authorization verification nodes. Auxiliary verification nodes provide supplementary verification and handle specific scenarios for the core verification nodes, including role verification nodes, permission operation review nodes, and emergency state declaration verification nodes. The directed edges connecting the nodes define the temporal relationships between the nodes. Based on the data access request and a preset verification dependency rule base, a unique and ordered access verification path is generated.

[0017] Specifically, providing supplementary verification and handling for specific scenarios includes:

[0018] Supplementary verification is designed as a condition-triggered mechanism, meaning that successful verification at the core node is a prerequisite for activating the corresponding auxiliary verification, dynamically adding more targeted audit steps; including but not limited to activating the role verification node by default after the organization trust verification node passes verification, serving as the basis for all subsequent judgments; parsing digital certificates to identify specific roles and enabling fine-grained authorization across organizations; and determining whether to activate the permission operation review node for further verification based on the specific role's level of permissions after the role verification node passes verification.

[0019] Handling specific scenarios means that when the core verification node fails due to not meeting the normal conditions, instead of directly denying access, an alternative path is initiated by multiple auxiliary nodes to cooperate in verification, in order to deal with special emergency situations. This includes, but is not limited to, when the dynamic authorization verification node fails to verify the patient in an emergency, activating the emergency declaration verification node to verify the authenticity of the emergency, and then entering the permission operation review node to further verify the validity of the request. By cooperating with two auxiliary nodes to replace the authorization task of the core node, information security is ensured while flexibly handling special emergency situations.

[0020] Specifically, the preset verification dependency rule base consists of condition-action rules, which are called sequentially during the dynamic construction of the access verification path, including:

[0021] Node activation rules determine whether a node is activated based on information in the data access request; path dependency rules determine the next path node based on the node activation status; equivalent substitution rules are triggered when the core verification node fails to verify, activating an alternative verification path to handle special emergency situations.

[0022] Preferably, the specific process for generating the verification path hash chain is as follows:

[0023] The verification digest includes the identifier of the verification node, the timestamp of successful verification, and the verification result; a hash operation is performed on the verification digest of the first verification node in the access verification path to obtain an initial hash value; the verification digests of subsequent verification nodes are concatenated with the previous hash value and hashed again to iteratively update the hash value; the hash value obtained after processing the last verification node is used as the verification path hash chain.

[0024] Preferably, the process of generating a one-time symmetric encryption key, encrypting the target medical data to obtain encrypted data content, and digitally signing the verification path hash chain to generate verification signature information is as follows:

[0025] A random number generator generates a one-time symmetric encryption key, and the target medical data is encrypted using the SM4 symmetric encryption algorithm to generate encrypted data content; the verification path hash chain is digitally signed using the SM2 algorithm to generate the verification signature information.

[0026] Preferably, the step of dynamically determining the target encryption strategy based on the sensitivity level specifically involves:

[0027] If the sensitivity level is "normal", then the target encryption strategy of the standard asymmetric encryption algorithm SM2 is adopted;

[0028] If the sensitivity level is "sensitive", then the digital certificate is required to have the purpose of extended key, that is, the target encryption strategy of the EKU attribute;

[0029] If the sensitivity level is "highly confidential", then a double-nested target encryption strategy is determined, requiring real-time approval from multiple authorized parties before using personal qualification credentials to obtain the data key.

[0030] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0031] 1. This invention abandons the traditional static, role-based access control model. It abstracts all possible verification requirements into a directed graph verification model consisting of "core verification nodes" and "auxiliary verification nodes." When a data access request is received, a pre-set rule base is used for real-time analysis to dynamically generate a unique and ordered access verification path tailored to this request from the graph model. More importantly, this invention generates a digest of each verification result of this dynamic path and constructs a cryptographically immutable "verification path hash chain" through iterative hash operations. Finally, this hash chain is digitally signed. This achieves refined and adaptive access control. The access control of this invention is no longer "one-size-fits-all," but can dynamically adjust the strictness of verification according to the specific context of each request. It achieves complete transparency and non-repudiation of the authorization process. Through the "verification path hash chain" and "digital signature," this invention transforms the process of "how to authorize" itself into a trustworthy and tamper-proof electronic evidence. In the event of a data security incident, every step of the authorization process can be traced immediately by verifying the hash chain and signature, clarifying responsibility.

[0032] 2. This invention establishes an encryption strategy system that dynamically matches data risk. It does not use the same encryption standard for all data, but rather employs different technical solutions in the key encapsulation stage based on the data's sensitivity level. This achieves optimal allocation of security resources. This invention avoids waste of security resources and insufficient protection capabilities. It can provide appropriate protection for data of different values, investing the strongest security guarantees in the most important data, achieving an extremely high cost-effectiveness for the overall security system.

[0033] 3. The final output of this invention is a structured "unified security data packet." Its innovation lies in the fact that it does not simply contain encrypted data, but rather atomically encapsulates four key components: encrypted data content; a strategically encapsulated key; a verification path hash chain recording the complete authorization process; and digital signature information proving the authenticity of the authorization process. This achieves data-centric security. The data packet itself is "self-contained, self-proving, and self-protecting." Security attributes no longer depend on the transmission channel or storage system, but follow the data itself. Regardless of how the data packet is copied, transmitted, or stored, its internal encryption protection and authorization credentials remain bound to it, greatly expanding the security boundaries of the data. It simplifies the complexity of establishing trust across institutions. The data recipient can not only decrypt the data but also independently verify the legitimacy of the authorization process without trusting a third party. Only the signature and hash chain within the data packet need to be verified to determine the compliance and authenticity of the data, which greatly reduces the cost of establishing technical trust between institutions and promotes secure and efficient data flow. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating a cross-institutional secure sharing encryption method for medical case data according to an embodiment of the present invention;

[0035] Figure 2 This is a schematic diagram of the process for constructing the dynamic access verification path according to an embodiment of the present invention;

[0036] Figure 3 This is a schematic diagram of the structure of the unified security data packet described in an embodiment of the present invention. Detailed Implementation

[0037] Next, the technical solution of the present invention will be explained in detail and clearly with reference to specific examples and related drawings. It should be understood that the examples described below represent only a part of the present invention, not all of it. Based on these examples, those skilled in the art can deduce other possible embodiments of the present invention without creative effort, and these embodiments are also protected by the present invention.

[0038] This invention relates to an encryption method for secure cross-institutional sharing of medical case data, the specific implementation steps of which are as follows:

[0039] Obtain data access requests and target medical data that include the target data identifier, the requester's digital certificate, access permission level, sensitivity level, and authorization status;

[0040] Based on preset verification dependencies, access verification paths are dynamically constructed for data access requests;

[0041] Access control verification is performed based on the access verification path, and the verification digest of each path node is recorded to form a verification path hash chain; if the access verification path is approved, the subsequent steps are executed.

[0042] A one-time symmetric encryption key is generated to encrypt the target medical data, resulting in encrypted data content. The verification path hash chain is then digitally signed to generate verification signature information.

[0043] Based on the sensitivity level, the target encryption strategy is dynamically determined; according to the target encryption strategy, the one-time symmetric encryption key is asymmetricly encrypted to generate a key encapsulation result;

[0044] The verification path hash chain, verification signature information, encrypted data content, and key encapsulation results are structurally encapsulated to generate a unified security data packet.

[0045] The technical solution of the present invention will be further described in detail below with reference to specific embodiments.

[0046] Example 1

[0047] This embodiment takes cross-organizational data sharing under normal circumstances as an example to illustrate the specific steps of this method in detail.

[0048] In this embodiment, the scenario is set as follows: Ms. Wang, a patient, has completed an annual physical examination at Community Health Service Center A and needs to undergo further health consultation at Hospital C, a tertiary hospital in the city.

[0049] Reference Figure 1 The specific implementation steps of the method proposed in this invention include:

[0050] S1. Obtain the data access request and target medical data, which include the target data identifier, the requester's digital certificate, access permission level, sensitivity level, and authorization status;

[0051] S2. Based on the preset verification dependency relationship, dynamically construct the access verification path for the data access request; perform access control verification according to the access verification path, record the verification digest of each path node, and form a verification path hash chain; if the access verification path is passed, execute the subsequent steps.

[0052] S3. Generate a one-time symmetric encryption key to encrypt the target medical data, obtain the encrypted data content, and digitally sign the verification path hash chain to generate verification signature information;

[0053] S4. Based on the sensitivity level, dynamically determine the target encryption strategy; according to the target encryption strategy, perform asymmetric encryption on the one-time symmetric encryption key to generate a key encapsulation result;

[0054] S5. The verification path hash chain, verification signature information, encrypted data content and key encapsulation result are structurally encapsulated to generate a unified security data packet.

[0055] Further, the process of obtaining the data access request and the target medical data, which includes the target data identifier, the requester's digital certificate, the access permission level, the sensitivity level, and the authorization status, corresponds to step S1 above. The specific process is as follows:

[0056] Inside the consultation room at Hospital C, after obtaining Ms. Wang's consent, the doctor initiated a data retrieval request to the regional health information platform through the doctor's information system on their workstation. The request information is as follows:

[0057] Target data identifier: "W510107..._TJR" (Ms. Wang's medical examination report number at Center A);

[0058] Requester's digital certificate: An SM2 digital certificate containing the doctor's identity information, public key, affiliated institution "Hospital C", and role "Associate Chief Physician";

[0059] Access permission level: Read-only;

[0060] Sensitivity level: Normal;

[0061] Authorization status: Pending.

[0062] The data sharing gateway at Center A receives the request and locks onto Ms. Wang's target medical data, namely her medical examination report.

[0063] Furthermore, based on preset verification dependencies, an access verification path is dynamically constructed for data access requests; access control verification is performed according to the access verification path, and the verification digest of each path node is recorded to form a verification path hash chain; if the access verification path is passed, the subsequent steps are executed, corresponding to step S2 above. The specific implementation process is as follows:

[0064] Center A's shared gateway initiates the access control module and processes data according to a pre-defined verification dependency rule base.

[0065] Specifically, the rule base consists of a series of "condition-action" (IF-THEN) rules, which the system queries and calls sequentially when constructing the verification path. The complete verification dependency rule base in this embodiment is shown in Tables 1, 2, and 3.

[0066] The node activation rules determine which verification nodes need to be included in the scope of this access verification based on the information in the initial data access request.

[0067] Table 1 Node Activation Rules

[0068]

[0069] Path-dependent rules define the execution order of nodes after they are activated, constructing an ordered verification path. The rule engine starts from the initial rule and determines the next node based on the verification results of each node.

[0070] Table 2 Path Dependency Rules Table

[0071]

[0072] Equivalent substitution rules handle special cases when core verification nodes fail, providing alternative verification paths and enhancing flexibility.

[0073] Table 3 Equivalent Substitution Rules

[0074]

[0075] By encapsulating specific rules (such as node activation conditions, path dependencies, and equivalent substitutions) into a rule base, access control policies are effectively separated from system execution mechanisms. This allows security policy administrators to easily set and modify complex and ever-changing access verification logic, much like setting firewall rules, without altering the system's internal source code structure. This significantly enhances the flexibility of security policy administrators and improves the maintainability, auditability, and responsiveness to future business needs.

[0076] When a conflict occurs in the rule base of the verification path, the conflict is resolved through a conflict handling strategy, and an access verification path is generated.

[0077] Specifically, the conflict handling strategy follows a core principle: the more specific and stringent the rule, the higher its priority. When all priority checks fail, the system defaults to performing the safest operation (i.e., denying access).

[0078] Rule type priority: Equivalent substitution rules, which specifically handle urgent or special cases when core verification fails, have the highest priority; path dependency rules define the main logic of the verification process and are the basis for building standard verification paths, so their priority is second; node activation rules play a role in the very beginning of path construction and are used to determine the verification scope, so their priority is the lowest.

[0079] Rule specificity priority: When two rules of the same type conflict, the system determines which rule has a more "specific" trigger condition. The rule with more specific and complex conditions has higher priority.

[0080] The default security failure principle is that if the conflict still exists after the first two levels of judgment, the system will execute the preset default security policy: immediately terminate path construction, reject the current data access request, record the conflict event log, and notify the system administrator to review and correct the rule base.

[0081] This multi-level arbitration mechanism provides a clear and unambiguous solution for all possible rule conflicts. For any given data access request, the final generated verification path is unique and deterministic, eliminating security risks that may arise from logical ambiguity and ensuring the stability and reliability of the system. When adding or modifying rules, policy administrators can clearly predict their priority within the entire system, making the iteration and maintenance of the rule base simpler and safer.

[0082] In this embodiment, based on the request information, the system activates the following core verification nodes: the institution trust verification node, the data sensitivity verification node, and the patient dynamic authorization verification node. Simultaneously, because the request includes a digital certificate, the role verification node is also activated. The rule base defines a standard verification process. Since there are no special or emergency situations, the system will construct a linear access verification path without alternative paths.

[0083] This significantly enhances the granularity and scenario adaptability of access control. On one hand, the "supplementary verification" mechanism (such as verifying the institution before verifying the role) enables progressively refined permissions, preventing security risks associated with coarse-grained authorization. On the other hand, the alternative path mechanism for "handling specific scenarios" perfectly solves the common emergency authorization problem in healthcare. When conventional conditions fail, such as the inability to obtain authorization from the patient, it provides a safe and flexible backup channel, balancing the efficiency of life-saving treatment with information security.

[0084] The generated access verification path is as follows:

[0085] Institutional trust verification node → Data sensitivity verification node → Patient dynamic authorization verification node → Role verification node; the system strictly follows the above path sequence for verification.

[0086] It achieves a dynamic and intelligent access control model. By introducing a graph-based verification path, access verification is transformed from a static "allow or not" judgment into a dynamic, on-demand constructed "verification process." Distinguishing between core and auxiliary verification nodes gives the security policy both a rigid foundation (core nodes ensure basic security) and flexible expansion (auxiliary nodes handle specific scenarios), significantly outperforming traditional, single, and rigid access control lists.

[0087] The institutional trust verification node needs to confirm that the requesting medical institution, namely Hospital C in this embodiment, is a legitimate partner within the trusted network, rather than an arbitrary unknown network entity. It extracts the organizational information of the requesting doctor from their digital certificate and performs identity and IP matching in a "Trusted Medical Consortium Member List" database maintained internally by Center A. If Hospital C is confirmed to be on the Trusted Medical Consortium Member List, the verification is successful, and a verification digest Z1 is generated for that node. An initial hash value H0 is then generated using hash operations.

[0088] H0 = SHA256(Z1).

[0089] The data sensitivity verification node automatically assesses the sensitivity level of target data requested by users. This rating directly impacts the stringency of subsequent authorization and encryption. The data type is parsed from the target data identifier in the request, and then matched against the sensitivity grading rule base within Center A. The data resources and sensitivity grading rule base contain sensitivity levels corresponding to different data information types, such as...

[0090] {type: Medical Examination Report, sensitivity: Normal}

[0091] {type: Inpatient Medical Record Cover Page, sensitivity: Sensitive}

[0092] {type: genetic testing report, sensitivity: highly confidential}

[0093] The primary task of this node is rating, rather than simply passing / failing. If the corresponding rule is successfully found and assigned a value, the verification is considered successful, and a verification digest Z2 is generated. Z2 is concatenated with H0, and the SHA256 hash algorithm is used again to calculate the next hash value H1.

[0094] H1 = SHA256(H0 + Z2).

[0095] The patient dynamic authorization verification node, based on the principle of informed consent, obtains real-time and explicit authorization from the patient for this specific data sharing behavior. The system automatically generates an authorization request message based on the request information. This message is pushed to Ms. Wang's mobile phone via an encrypted channel for her authorization. Within a set time window (e.g., 120 seconds), if a data packet with a "agree" response is received and the digital signature in the packet is successfully verified using the pre-stored patient public key, verification is considered successful, and a verification digest Z3 is generated; if the patient chooses "decline," or the response times out, or the signature verification fails, verification is considered unsuccessful. Verification digest Z3 is concatenated with hash value H1 to generate the next hash value H2.

[0096] H2 = SHA(H1 + Z3).

[0097] The role verification node, with the consent of both the institution and the patient, serves as the final checkpoint to ensure that the operator's professional role and permissions match the sensitivity of the requested data. The role and department fields are parsed from the digital certificate, and the extracted role is combined with the data sensitivity to form a query condition. This is then matched against the access control and permission policy library within Center A, which uses a "role-operation-resource" rule pattern, for example...

[0098] {role: Doctor, permission: Read, data_level: Normal}

[0099] {role: Chief Physician, permission: Read, data_level: Sensitive}

[0100] {role: Head of Medical Affairs, permission: ReadWrite, data_level: Top Secret}

[0101] The system queries the policy library. If a matching, allowed rule exists, it is verified, and a verification digest Z4 is generated. The verification digest Z4 is concatenated with the hash value H2, and then the hash value H3 is calculated using the SHA256 algorithm.

[0102] H3 = SHA256(H2 + Z4),

[0103] The hash value H3 serves as the verification path hash chain H3.

[0104] It provides a tamper-proof, traceable access verification audit log. The verification path hash chain cryptographically links the verification results of each step, and any modification to the historical record will cause the chain to break. This provides strong, irrefutable technical evidence for post-event auditing and accountability, effectively solving the "trust" and traceability problems in the data sharing process.

[0105] Further, a one-time symmetric encryption key is generated to encrypt the target medical data, obtaining the encrypted data content. The verification path hash chain is then digitally signed to generate verification signature information. Corresponding to step S3 above, the specific implementation process is as follows:

[0106] The system generates a new 128-bit SM4 key (OTK) using a random number generator. Using this OTK and the SM4 algorithm, Ms. Wang's medical examination report is encrypted, generating encrypted data. Center A's data sharing gateway uses its institutional private key and the SM2 algorithm to sign the verification path hash chain H3, generating verification signature information.

[0107] This ensures the standardization and high security of the cryptographic algorithms used in the method. By explicitly adopting the national standard SM4 (symmetric encryption) and SM2 (asymmetric encryption, digital signature) algorithms, the technical solution complies with national security standards, has strong encryption protection, and facilitates interoperability and compliance within the domestic medical system.

[0108] Furthermore, based on the sensitivity level, a target encryption strategy is dynamically determined; according to the target encryption strategy, the one-time symmetric encryption key is asymmetric encrypted to generate a key encapsulation result. Corresponding to step S4 above, the specific implementation process is as follows:

[0109] The key input obtained by the policy engine is the data sensitivity level = normal. It then queries the internally configured encryption policy rule base, which defines the mapping relationship between different sensitivity levels and key encapsulation policies. For example...

[0110] IFsensitivity==NormalTHENstrategy=SM2_Standard_Envelope

[0111] IFsensitivity==sensitivity THENstrategy=SM2_EKU_Check_Envelope

[0112] IFsensitivity == Highly Confidential THENstrategy = SM2_Nested_MultiParty_Envelope

[0113] In this embodiment, the engine matches the first rule, and therefore, ultimately determines to use the most basic standard asymmetric encryption algorithm SM2 as the target encryption strategy. The publicly available SM2 public key, which can be used for encryption, is directly extracted from the requester's digital certificate of this data access request. Then, this public key and the SM2 algorithm are used to encrypt the key, generating a key encapsulation result.

[0114] This method achieves risk-adaptive differentiated encryption protection. It directly links the protection strength of the encryption key to the sensitivity level of the data itself, employing different key encapsulation strategies for "ordinary," "sensitive," and "highly confidential" data. This avoids either indiscriminate over-encryption (impacting efficiency) or insufficient encryption (leaving hidden dangers) for all data, enabling refined and rational allocation of security resources, and optimizing system performance and availability while ensuring security.

[0115] Furthermore, the verification path hash chain, verification signature information, encrypted data content, and key encapsulation result are structurally encapsulated to generate a unified security data packet. Corresponding to step S5 above, the specific implementation process is as follows:

[0116] The system incorporates the verification path hash chain (H3), verification signature information (SM2 signature of H3), encrypted data content (encrypted medical examination report), and key encapsulation result (OTK encrypted with the doctor's public key) into a preset data structure to generate a unified security data packet (USDP).

[0117] Specifically, the unified security data packet is logically divided into four main parts:

[0118] The packet header contains metadata about the data packet, such as the protocol version, a unique packet ID, a generation timestamp, and identifiers of the communicating parties. This information helps in packet management, routing, and parsing.

[0119] The authorization certificate encapsulates all cryptographic evidence related to the authorization process. It stores the final verification path hash chain, which the recipient can use to verify whether the authorization process has been tampered with. It also stores the data provider's digital signature on the hash chain, which the recipient can verify using the provider's public key, thus confirming the authenticity and non-repudiation of the entire authorization process.

[0120] The key information encapsulates the key used to decrypt core data. It includes a one-time symmetric key (OTK) encrypted with the requested party's public key. Only the legitimate requester holding the corresponding private key can decrypt this encrypted portion and obtain the OTK used to decrypt medical data.

[0121] The data payload is the core content of the data packet. It contains the medical data itself, encrypted using OTK.

[0122] This data packet can now be transmitted as a standalone, complete unit over any network channel (such as HTTPS, FTP, or instant messaging) or stored on any medium (such as a database or object storage).

[0123] The final output of this invention is a "self-contained, self-proving, and self-protecting" secure data unit. Security attributes no longer rely solely on the security of the transport channel (such as VPN or TLS), but are embedded within and follow the data itself. Regardless of how the data packet is copied, transmitted, or stored, its internal encryption protection and authorization credentials remain strongly bound to it, greatly expanding the data's security boundary and effectively preventing the risk of data leakage after leaving the secure channel and reaching the endpoint system.

[0124] This USDP is transmitted to the doctor's client at Hospital C via a secure network channel. The doctor's client software automatically uses its locally stored private key, paired with the digital certificate, to decrypt the key-encapsulated result, thus obtaining the OTK. Subsequently, the OTK is used to decrypt the encrypted data content to obtain the original medical examination report. The integrity and authenticity of the entire data request's verification path are verified using the signature information and the verification path hash chain.

[0125] Example 2

[0126] This example illustrates information sharing in an emergency. Mr. Zhao was involved in a serious traffic accident while traveling in City D and was rushed to the City D Emergency Center, where he was in a deep coma upon arrival. The City D Emergency Center needs to request Mr. Zhao's medical data from the City E Central Hospital, which Mr. Zhao frequently visits.

[0127] Dr. Wang from the Emergency Center in City D initiated a data access request to the shared platform of the Central Hospital of City E through his hospital's emergency information channel. This request was specifically marked as "urgent".

[0128] Target data identifier: "Z340103..._CID_ALL" (All key medical records of patient Mr. Zhao at the E City Central Hospital)

[0129] Requester's digital certificate: Dr. Wang's personal SM2 digital certificate, which includes his identity as "Attending Physician of Emergency Department".

[0130] Access permission level: Read-only

[0131] Sensitivity level: "Top Confidential" (Automatically determined by the system based on the request content, such as "allergy history, blood type")

[0132] Authorization status: "Urgent - Pending" (The request explicitly includes the "urgent" flag).

[0133] Upon receiving the request, the shared gateway of City Center Hospital E's access control module's rule base begins operation. Regular nodes are activated: institution trust verification, data sensitivity verification, patient dynamic authorization verification, and role verification. Two additional auxiliary nodes are activated: an emergency declaration verification node and a permission operation review node. These two nodes are currently in standby mode.

[0134] The system begins performing verification along the path. At the institution trust verification node, the E City Central Hospital's system queries the National Medical Emergency Network member list, confirming that the D City Emergency Center is a legitimate and trusted medical institution. Verification passes, generating verification summary 1, and calculating H0.

[0135] At the data sensitivity verification node, the system confirms that the requested data involves allergy history, etc., and is rated as "highly confidential". Verification summary 2 is generated, and H1 is calculated.

[0136] The system attempts to send an authorization request to the mobile phone registered by patient Mr. Zhao during the dynamic authorization verification process. However, due to the patient's coma, the device is unresponsive, and the request times out after a preset 120 seconds. The core node verification fails, generating verification summary 3 and calculating H2.

[0137] The alternative path is activated. The system detects that the dynamic authorization verification for the patient at the core node has failed, but it does not directly deny access. It queries the equivalent alternative rule base, and the verification process is seamlessly switched to the preset emergency response plan.

[0138] The emergency declaration verification node sends an instruction to Dr. Wang's client at the D City Emergency Center via an interface, requesting him to submit a digitally signed emergency declaration. Upon receiving the declaration, the E City Central Hospital system uses Dr. Wang's public key (obtained from his certificate) to verify the digital signature, confirming its authenticity, integrity, and that it was issued by Dr. Wang himself. If the verification passes, a verification digest 4 is generated, and H3 is calculated.

[0139] Once the emergency declaration passes verification, it must enter the review process. This request is automatically and with high priority pushed to the approval queue of the duty director of the medical affairs department at E City Central Hospital. This director has the highest authority to handle such emergency medical information access. The duty director can see a complete snapshot of the event on their interface: the request from the trusted emergency center, the emergency declaration requesting the doctor's signed responsibility, and the failed record of the patient's inability to authorize access. They quickly determine if the situation is true, verify it, generate verification summary 5, and calculate H4.

[0140] After the role verification node completes the replacement process, it continues with necessary verification. It parses Dr. Wang's certificate, confirms that his role as "Attending Physician in the Emergency Department" matches the operation requested, verifies successfully, generates verification summary 6, and calculates H5.

[0141] The final verification path hash chain records the entire process from the failure of regular authorization to the successful start and passage through the emergency alternative path, which has extremely high auditing value.

[0142] The system uses the SM4 algorithm and a one-time key (OTK) to encrypt the highly confidential data of patient Mr. Zhao, and uses the private key of E City Central Hospital to perform SM2 signature on the verification path hash chain (H5).

[0143] Because the data is classified as "highly confidential," the system selects the most secure double-nested encryption strategy.

[0144] Specifically, the double-nested encryption strategy is a hybrid threshold and attribute key encapsulation method. The event-based authorization layer uses threshold cryptography for encapsulation, and its decapsulation requires real-time collaborative operation from multiple pre-defined authorization entities. This ensures that every data access behavior must obtain dynamic, multi-party, and immediate permission. The eligibility layer uses policy cryptography for encapsulation, and its decapsulation depends on the cryptographic credentials held by the accessor that conform to the predetermined access policy. This ensures that the accessor possesses static eligibility to access this type of data. First, by obtaining real-time approval from multiple authorization parties, the outer event-based authorization lock is unlocked; then, using its own eligibility credentials that conform to the rules, the inner eligibility lock is unlocked, and finally, the data key can be obtained.

[0145] An attacker must accomplish two extremely difficult tasks simultaneously: first, to compromise and control multiple approvers (reaching the threshold number) in real time, either physically or over a network; and second, to steal the requester's ABE private key, which contains all the correct attributes. This significantly enhances information security. The t-out-of-n threshold mechanism is far more flexible and efficient than "multi-party approval," which requires the approval of all specific individuals, greatly improving availability and preventing process interruptions due to individual approvers being away on business or vacation. The ABE layer ensures that only those meeting the preset "qualifications" can access the system, while the threshold layer ensures that every access request must undergo real-time, traceable human (or semi-automatic) approval, achieving a perfect combination of policy and auditing.

[0146] All parts are encapsulated into a unified secure data packet and sent to Dr. Wang at the D City Emergency Center, enabling him to obtain the information in a timely manner and provide the most effective treatment for the patient.

[0147] Example 3

[0148] This embodiment aims to demonstrate the specific technical process of key encapsulation for data at the "sensitive" level.

[0149] When the system enters the key encapsulation phase, its built-in policy engine determines the encryption strength to use based on the output of previous steps. The policy engine obtains the key input parameter from the verification process: Data Sensitivity Level = Sensitive. The engine queries its internal encryption policy rule base to match policy rules. If the engine successfully matches a target encryption policy that requires the digital certificate to have an Extended Key (EKU) attribute, this policy mandates a check on the requester's certificate's EKU attribute before performing SM2 encryption.

[0150] Extended Key Usage (EKU) is a standard extension in digital certificates. It uses a series of Object Identifiers (OIDs) to precisely define the specific application scenarios in which the certificate (and its associated key) can be used, thus going beyond basic uses such as "digital signatures" and "key encryption".

[0151] The system parses the requester's digital certificate, locates the "Extended Key Purpose" field, and iterates through the list of all OIDs contained in this field. The system checks if a pre-defined OID exists in this list. If it does, the verification passes, indicating that the doctor has the authority to process this type of sensitive data; if it does not exist, the verification fails, the entire key encapsulation process stops here, and an insufficient permission error is returned, without any encryption operation being performed.

[0152] After the EKU verification passes, the system identifies the object to be encapsulated, namely the 128-bit SM4 one-time key. The system extracts the SM2 public key from the doctor's digital certificate, which has just passed the EKU verification. The extracted SM2 public key is then used to encrypt the one-time key, generating the encrypted OTK, i.e., the key encapsulation result.

[0153] Although specific examples of the invention have been shown, those skilled in the art will understand that various adjustments, modifications, substitutions, and improvements can be made to these examples without departing from the core principles and spirit of the invention. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for securely sharing encrypted medical case data across institutions, characterized in that, Includes the following steps: Obtain data access requests and target medical data that include the target data identifier, the requester's digital certificate, access permission level, sensitivity level, and authorization status; Based on the preset verification dependencies, an access verification path is dynamically constructed for data access requests. The specific implementation process is as follows: Define a verification request graph model, which consists of nodes and directed edges connecting the nodes; the nodes are divided into core verification nodes and auxiliary verification nodes; the core verification nodes are the basis for each access verification, including data sensitivity verification nodes, institutional trust verification nodes, and patient dynamic authorization verification nodes. Auxiliary verification nodes provide supplementary verification and handle specific scenarios to the core verification nodes, including role verification nodes, permission operation review nodes, and emergency state declaration verification nodes; The directed edges connecting the nodes define the temporal relationship between the nodes; based on the data access request, a unique and ordered access verification path is generated based on a preset verification dependency rule base. The provision of supplementary verification and handling for specific scenarios specifically includes: Supplementary verification is designed as a condition-triggered mechanism, meaning that successful verification at the core node is a prerequisite for activating the corresponding auxiliary verification, dynamically adding more targeted audit steps; including but not limited to activating the role verification node by default after the organization trust verification node passes verification, serving as the basis for all subsequent judgments; parsing digital certificates to identify specific roles and enabling fine-grained authorization across organizations; and determining whether to activate the permission operation review node for further verification based on the specific role's level of permissions after the role verification node passes verification. Handling specific scenarios means that when the core verification node fails due to not meeting the normal conditions, instead of directly denying access, an alternative path is initiated by multiple auxiliary nodes to cooperate in verification, in order to deal with special emergency situations. This includes, but is not limited to, when the dynamic authorization verification node fails to verify the patient in an emergency, activating the emergency state declaration verification node to verify the authenticity of the emergency, and then entering the permission operation review node to further verify the validity of the request. By cooperating with two auxiliary nodes, the authorization task of the core node is replaced, ensuring information security while flexibly handling special emergency situations. Access control verification is performed based on the access verification path, and the verification digest of each path node is recorded to form a verification path hash chain; if the access verification path is approved, the subsequent steps are executed. A one-time symmetric encryption key is generated to encrypt the target medical data, resulting in encrypted data content. The verification path hash chain is then digitally signed to generate verification signature information. Based on the sensitivity level, the target encryption strategy is dynamically determined; According to the target encryption strategy, the one-time symmetric encryption key is asymmetricly encrypted to generate a key encapsulation result; The verification path hash chain, verification signature information, encrypted data content, and key encapsulation results are structurally encapsulated to generate a unified security data packet.

2. The cross-institutional secure sharing encryption method for medical case data according to claim 1, characterized in that, The preset verification dependency rule base consists of condition-action rules, which are called sequentially during the dynamic construction of access verification paths. These rules include: node activation rules, which determine whether a node is activated based on information in the data access request; path dependency rules, which determine the next path node based on the node activation status; and equivalent substitution rules, which are triggered when the core verification node fails to verify, activating an alternative verification path to handle special emergency situations.

3. The cross-institutional secure sharing encryption method for medical case data according to claim 1, characterized in that, The specific process for generating the verification path hash chain is as follows: The verification digest includes the identifier of the verification node, the timestamp of successful verification, and the verification result; a hash operation is performed on the verification digest of the first verification node in the access verification path to obtain an initial hash value; the verification digests of subsequent verification nodes are concatenated with the previous hash value and hashed again to iteratively update the hash value; the hash value obtained after processing the last verification node is used as the verification path hash chain.

4. The cross-institutional secure sharing encryption method for medical case data according to claim 1, characterized in that, The process of generating a one-time symmetric encryption key, encrypting the target medical data to obtain encrypted data content, and digitally signing the verification path hash chain to generate verification signature information is as follows: A random number generator generates a one-time symmetric encryption key, and the target medical data is encrypted using the SM4 symmetric encryption algorithm to generate encrypted data content; the verification path hash chain is digitally signed using the SM2 algorithm to generate the verification signature information.

5. The cross-institutional secure sharing encryption method for medical case data according to claim 1, characterized in that, The dynamic determination of the target encryption strategy based on the sensitivity level specifically includes: If the sensitivity level is "normal", then the target encryption strategy of the standard asymmetric encryption algorithm SM2 is adopted; If the sensitivity level is "sensitive", then the digital certificate is required to have the purpose of extended key, that is, the target encryption strategy of the EKU attribute; If the sensitivity level is "highly confidential", then a double-nested target encryption strategy is determined, requiring real-time approval from multiple authorized parties before using personal qualification credentials to obtain the data key.

Images