A blockchain-based medical data privacy protection and sharing method and system

Abstract

A blockchain-based medical data privacy protection and sharing method and system relate to the field of data processing. The method comprises: in response to an emergency access request containing a patient address, calling a preset smart contract; obtaining the requester identity validity, geographical location matching and patient emergency event record from an off-chain trusted data source, and aggregating them into a scenario verification factor group; generating an emergency state consensus proof when the number of factors in the group that meet the conditions reaches a preset threshold; generating a temporary session key that can only decrypt an emergency data subset within a valid period according to the proof; sending the key to the requester, and recording the access request, verification factors and consensus proof in the form of an unalterable transaction on the blockchain. The technical scheme provided by the application takes into account the dual needs of timeliness and privacy protection of medical data calling.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a blockchain-based method and system for protecting and sharing medical data privacy. Background Technology

[0002] To address the data silos in the healthcare field and protect patient privacy, blockchain-based personal health data management solutions have emerged. Leveraging the decentralized and immutable characteristics of blockchain, a patient-centric data sharing model is constructed. Under this model, patients have autonomous control over their health data and can manage data access permissions through smart contracts, thereby promoting secure data flow while ensuring effective protection of personal privacy.

[0003] In handling emergency data access scenarios, relevant technologies primarily employ two implementation paths. One is a pre-defined multi-party authorization mechanism, executed through smart contracts, requiring multiple trusted parties (such as family members and doctors) pre-designated by the patient to jointly provide digital signatures. Data can only be unlocked after a preset threshold is met. The other is an authoritative arbitration mechanism, relying on a trusted centralized entity (such as a hospital ethics committee). This entity conducts offline review and verification of emergency access requests, and grants access permission using its administrative authority after the review is passed.

[0004] However, in extreme situations where the authorizing party is absent and the situation is urgent, the effectiveness of pre-established multi-party authorization mechanisms heavily relies on the immediate response capabilities of the granting party, making it difficult to handle situations where all parties fail. Meanwhile, authoritative arbitration mechanisms, to mitigate their own decision-making risks, require rigorous verification procedures in their internal review processes. In urgent requests with incomplete information, this process, designed to ensure compliance, inherently creates a contradiction between its time-consuming nature and the extreme timeliness requirements of emergency treatment. Summary of the Invention

[0005] This application provides a blockchain-based method and system for protecting and sharing medical data privacy, which addresses the dual needs of timely access to medical data and privacy protection.

[0006] The first aspect of this application provides a blockchain-based method for protecting and sharing medical data privacy, the method comprising: Upon receiving an emergency access request, the system invokes a pre-deployed emergency access smart contract based on the target patient's blockchain account address. It then obtains identity validity proof from an identity authentication authority based on the authenticated digital identity from an off-chain trusted data source, compares the requester's device's geographic location information with a pre-defined medical institution geofence to generate a geographic location matching result, and obtains summaries of all emergency event records associated with the target patient from the public safety service system. These summaries form a scenario verification factor group corresponding to the emergency access request. Based on scenario verification rules, if the number of factors meeting the conditions in the scenario verification factor group is greater than or equal to a pre-defined factor number threshold, an emergency state consensus proof is generated. In response to the emergency state consensus proof, a temporary session key is generated, which can only decrypt a subset of emergency data within a pre-defined validity period. The temporary session key is sent to the requester, and the emergency access request, scenario verification factors, and emergency state consensus proof are recorded on the blockchain in an immutable transaction format.

[0007] In the above embodiments, a scenario verification factor group is introduced, with smart contracts as the core of execution, to comprehensively evaluate multi-dimensional information such as identity, geographical location, and public event records. This threshold judgment mechanism based on multi-source evidence enables authorization decisions to be automated and respond quickly to real emergency scenarios. Simultaneously, the generation of temporary session keys limits the scope and timeliness of access, and the use of immutable on-chain records ensures post-event traceability, thus achieving a balance between the immediacy of data access and patient privacy security during rescue operations.

[0008] In conjunction with some embodiments of the first aspect, in some embodiments, in response to an emergency state consensus proof, a temporary session key is generated that can only decrypt a subset of emergency data within a preset validity period, specifically including: In response to the emergency state consensus proof, based on geographical location information and the timestamp corresponding to the emergency event request, an immutable spatiotemporal trust domain with a preset spatial radius and effective time window is defined on the blockchain. The blockchain account addresses of rescuers and injured persons within the spatiotemporal trust domain are mapped and recorded as a temporary authorized rescuer list and an emergency concern patient list, and these lists are maintained as on-chain states associated with the spatiotemporal trust domain. In response to a valid access request originating from an address in the temporary authorized rescuer list and pointing to an address in the emergency concern patient list, the step of repeatedly performing the emergency state consensus proof is replaced by verifying that the requester's address exists in the temporary authorized rescuer list and the target patient's address exists in the emergency concern patient list. Based on the verification result, a temporary session key is generated. After the effective time window of the spatiotemporal trust domain expires, the permission to trigger key generation based on the list state is terminated, and the final states of the temporary authorized rescuer list and the emergency concern patient list, along with all access logs, are archived immutably as audit records.

[0009] In the above embodiments, an immutable spatiotemporal trust domain is defined on the blockchain after an emergency consensus is reached, creating an authorization boundary for mass incidents. Within this domain, a temporary list of authorized rescuers and patients is pre-generated, transforming the one-time mass consensus into lightweight list verification for subsequent high-frequency access. This simplifies the repetitive and complex authentication process into an efficient list lookup, improving the efficiency of data retrieval for on-site collaborative rescue. Finally, as the preset time window expires, the permissions automatically terminate, leaving a complete on-chain audit record. This ensures unimpeded access to the rescue green channel while implementing strict lifecycle control over access to sensitive data, achieving a balance between emergency response efficiency and privacy security.

[0010] In conjunction with some embodiments of the first aspect, in some embodiments, verifying that the requester's address exists in the temporary authorized rescuer list and the target patient's address exists in the emergency concern patient list replaces the step of repeatedly performing emergency consensus proof on the access request, and triggers the generation of a temporary session key based on the verification result, specifically including: When an on-chain transaction expressing a privacy claim is received from a target patient, the account address of the corresponding target patient in the list of patients in urgent need of attention is marked as a supervised conditional access state. The requester's address is verified to exist in the list of temporary authorized rescuers, the target patient's address is in the list of patients in urgent need of attention, and it is determined whether the target patient's address is in a conditional access state. If so, after obtaining confirmation information from a third party, the generation of a temporary session key is triggered.

[0011] In the above embodiments, by empowering patients to proactively declare their privacy rights through on-chain transactions in emergency situations and setting a supervised access status, patient privacy is transformed into an enhanced rather than blocking authorization process. Subsequent access requires confirmation from a third party with supervisory authority within the rescue team. This ensures that privacy supervision is both authoritative and efficient, avoiding delays in treatment due to the introduction of external processes. Ultimately, while respecting the patient's personal wishes, necessary channels for emergency medical intervention are preserved, achieving a dynamic balance between patient privacy and efficient treatment.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, based on scenario verification rules, when the number of factors satisfying the conditions in the scenario verification factor group is greater than or equal to a preset factor number threshold, an emergency state consensus proof is generated, specifically including: The system monitors all emergency access requests within a preset time window. When the number of emergency access requests originating from a unified preset geofence exceeds a mass event threshold, it stops calling external data sources and broadcasts a cryptographic challenge requesting near-field peer-to-peer authentication to the authenticated digital identities of all requesters. It receives neighbor authentication beacons returned by the requester's device and cross-verifies the validity of the geographic coordinates, timestamps, and signatures of both parties encapsulated in the neighbor authentication beacons. It establishes temporary mutual trust scores for all requesters within the domain, accumulating the scores based on the number of times the signer appears in different successfully verified neighbor authentication beacons. Once a requester's mutual trust score reaches a preset mass consensus threshold, it generates an emergency state consensus proof for the corresponding requester.

[0013] In the above embodiments, when a mass incident is detected, the reliance on external data sources is terminated, and a decentralized on-site consensus mechanism is initiated instead. By broadcasting cryptographic tasks for mutual authentication between near-field peer nodes, on-site personnel and devices can mutually verify physical coexistence. The scheme quantifies this mutual authentication relationship as a mutual trust score, thereby rapidly establishing a temporary, self-organizing trust network at the rescue site. This design bypasses the bottleneck of potential external communication failures, ensuring that authorization no longer relies on a single center or external system but is completed within the group, guaranteeing the immediacy and reliability of data access under extreme conditions while also ensuring access security.

[0014] In conjunction with some embodiments of the first aspect, in some embodiments, after establishing temporary mutual trust scores for all requesters within the domain and accumulating the scores based on the number of times the signer appears in different neighboring mutual verification beacons that have been successfully verified, the method further includes: The trust relationship topology graph formed by all verified neighboring mutual authentication beacons is analyzed, and the trust clusters in the internal nodes are identified using a graph clustering algorithm. For each trust cluster, the cluster size and mutual authentication completeness are calculated independently, and the cluster credibility is generated by combining the cluster size and mutual authentication completeness. When the cluster credibility of a trust cluster exceeds a preset cluster authentication threshold, the corresponding trust cluster is designated as a trusted rescue unit. In response to the overall authentication of the trusted rescue unit, an emergency state consensus proof is generated for all member requesters within the trusted rescue unit.

[0015] In the above embodiments, the mutual authentication relationships between on-site nodes are abstracted into a trust relationship topology graph, and a graph clustering algorithm is used to identify tightly connected trust clusters. By quantitatively evaluating the size and internal mutual authentication completeness of each cluster, truly collaborative rescue teams are identified and authenticated as trusted rescue units. This leap from authenticating individuals to authenticating collectives simplifies and accelerates the authorization process, enabling the activation of organized rescue forces. Ultimately, while ensuring the authenticity of group consensus, rapid granting of on-site team-level permissions is achieved, ensuring data security while gaining valuable time for rescue operations.

[0016] In conjunction with some embodiments of the first aspect, in some embodiments, based on the authenticated digital identity, a validity certificate is obtained from an identity authentication authority from an off-chain trusted data source; a geographic location matching result is generated by comparing the requester's device's geographic location information with a preset medical institution geofence; and a summary of all emergency event records associated with the target patient is obtained from a public safety service system. These components form a scenario verification factor set corresponding to the emergency access request, specifically including: After all the pre-set off-chain trusted data sources fail to be called, the external calls are stopped. By parsing the historical transaction records of the target patient's blockchain account, the counterparties who have had more than a pre-set number of interaction records with the requester's certified digital identity are identified and adopted as social relationship factors. The scenario verification factor group is reconstructed based on the alternative factors to obtain the reconstructed scenario verification factor group.

[0017] In the above embodiments, under the extreme scenario of complete disconnection from all external trusted data sources, high-frequency on-chain interactions are identified as credible social relationship factors by analyzing the patient's blockchain account history. This transforms immutable on-chain data into alternative evidence of real-world trust, thereby reconstructing the scenario verification factor set. This ensures that even in information silos, the authorization process can continue based on on-chain facts, guaranteeing uninterrupted rescue efforts while providing a traceable and secure basis for this special authorization, achieving a balance between emergency response speed and data access security.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, before invoking the pre-deployed emergency access smart contract based on the target patient's blockchain account address after receiving an emergency access request, the method further includes: In response to a special emergency access request that receives a blockchain account address for a missing target patient but contains an official disaster event identifier, the system invokes the public safety service system to verify the disaster event identifier and obtains the certified special disaster event geofence and special effective time window. Based on the biometric information collected in real time on-site by the special requester, a temporary special blockchain account address is generated and used to replace the original blockchain account address to initiate the emergency access smart contract. The fact that both the requester's device geographic location information and the geographic location information recorded when collecting biometric information are located within the special disaster event geofence and special effective time window is used as a mandatory core verification factor. Based on the satisfaction of the mandatory core verification factor, an emergency consensus proof is generated, and access is only authorized to a predefined subset of primary emergency medical data.

[0019] In the above embodiments, in extreme situations involving unidentified injured persons during large-scale disasters, the spatiotemporal authentication boundaries are defined by official disaster event identifiers. Temporary blockchain accounts are generated for the injured persons, and the fact that the rescuers and the injured persons coexist in the disaster area serves as a mandatory core verification factor, thereby shifting the authorization basis from identity to a verifiable context. Necessary access permissions are granted immediately, while strictly limiting permissions to a subset of primary emergency medical data, ultimately achieving a balance between ensuring the golden time for rescue and protecting potential individual privacy.

[0020] Secondly, embodiments of this application provide a medical data privacy protection and sharing system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the medical data privacy protection and sharing system to perform the method described in the first aspect and any possible implementation thereof.

[0021] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on a medical data privacy protection and sharing system, cause the medical data privacy protection and sharing system to perform the method described in the first aspect and any possible implementation thereof.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a medical data privacy protection and sharing system, cause the medical data privacy protection and sharing system to perform the method described in the first aspect and any possible implementation thereof.

[0023] It is understood that the medical data privacy protection and sharing system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the blockchain-based medical data privacy protection and sharing method provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0024] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. This application uses smart contracts as its core execution mechanism and introduces a scenario verification factor group to comprehensively evaluate multi-dimensional information such as identity, geographical location, and public event records. This threshold judgment mechanism based on multi-source evidence enables authorization decisions to be automated and respond quickly to real emergency scenarios. Simultaneously, the generation of temporary session keys limits the scope and timeliness of access, and the use of immutable on-chain records ensures post-event traceability, thus achieving a balance between the immediacy of data access and patient privacy security during rescue operations.

[0025] 2. This application establishes an immutable spatiotemporal trust domain on the blockchain after an emergency consensus is reached, creating an authorization boundary for mass incidents. Within this domain, by pre-generating temporary authorized rescuer and patient lists, the one-time mass consensus is transformed into lightweight list verification for subsequent high-frequency access. This simplifies the repetitive and complex authentication process into an efficient list lookup, improving the efficiency of data retrieval for on-site collaborative rescue. Finally, as the preset time window expires, permissions automatically terminate, leaving a complete on-chain audit record. This ensures unimpeded access to the rescue green channel while implementing strict lifecycle control over access to sensitive data, achieving a balance between emergency response efficiency and privacy security.

[0026] 3. This application empowers patients to proactively declare their privacy rights through on-chain transactions in emergency situations, establishing a supervised access status. This transforms patient privacy into an enhanced, rather than blocking, authorization process, requiring subsequent access from a third party with oversight authority within the rescue team. This ensures authoritative and efficient privacy oversight, avoiding delays in treatment due to the introduction of external processes. Ultimately, while respecting patients' personal wishes, it also preserves necessary channels for emergency medical intervention, achieving a dynamic balance between patient privacy and efficient treatment. Attached Figure Description

[0027] Figure 1 This is a flowchart illustrating a blockchain-based method for protecting and sharing medical data privacy in an embodiment of this application. Figure 2 This is another flowchart illustrating the blockchain-based medical data privacy protection and sharing method in this application embodiment; Figure 3 This is an exemplary hardware structure diagram of a medical data privacy protection and sharing system in the embodiments of this application. Detailed Implementation

[0028] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0029] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0030] In related technologies, handling the authorization issue of emergency data access mainly relies on two preset paradigms. The first is a mechanism based on multi-signature authorization, requiring multiple authorized parties (such as family members and attending physicians) pre-designated by the patient to jointly provide digital signatures. Once a preset threshold is met, a smart contract automatically unlocks the data. However, in major disasters where the authorized parties themselves may be in danger or unable to respond immediately, this mechanism can become paralyzed due to the collective absence of the authorizing parties, leading to an interruption of the authorization chain. The second model involves arbitration through an authoritative centralized institution, such as a hospital ethics committee conducting offline review and verification of emergency requests. To ensure rigorous and compliant decision-making, this model often involves a cautious and time-consuming internal review process. When faced with incomplete information and an extremely urgent on-site request for help, this procedure, designed to mitigate risk, inherently creates a contradiction between its time delay and the urgent need for life-saving treatment.

[0031] In this embodiment, instead of relying on a fixed authorizing party, a scenario verification factor set is introduced. Using an emergency access smart contract as the execution core, multiple independent off-chain trusted data sources are invoked to aggregate multi-dimensional, weakly correlated objective information, such as the requester's identity validity, geographical location, and records of public emergency events related to the patient, into a dynamic set of evidence. The smart contract automatically evaluates the sufficiency of this evidence according to preset rules. Once the number of factors meeting the conditions reaches a threshold, the emergency scenario is considered valid, and an emergency state consensus proof is automatically generated. This improves the timeliness of authorization decisions. Simultaneously, by generating temporary session keys that are limited to specific data subsets and have an expiration date, and recording the entire authorization process in an immutable form on the blockchain, access permissions and scope are strictly constrained, ensuring transparency and credibility in post-event auditing. Ultimately, while ensuring the timeliness of the rescue response, the privacy and security of the patient's medical data are also considered.

[0032] Figure 1 This is a flowchart illustrating the blockchain-based medical data privacy protection and sharing method used in the embodiments of this application, including the following steps: S101. Upon receiving an emergency access request, the pre-deployed emergency access smart contract is invoked based on the target patient's blockchain account address.

[0033] An emergency access request is a digital instruction encapsulating specific data and designed to trigger an emergency medical data access process. It is typically issued by the terminal device of emergency responders and includes the requester's authenticated digital identity and the target patient's blockchain account address. The target patient's blockchain account address is a string of characters uniquely identifying the patient on the blockchain network, serving as an electronic credential of data ownership, such as a 42-bit Ethereum address starting with "0x". A pre-deployed emergency access smart contract is automated program code written and published to the blockchain before the emergency occurs. Its address is public, and its code logic is immutable. It predefines scenario verification rules and the access scope of a subset of emergency data. The requester's authenticated digital identity is an encrypted credential issued by a trusted third party (such as an industry association or certification body) that verifies the requester's true professional identity (such as a doctor or nurse), for example, based on W3C. Digital identities based on DID (Decentralized Identity) and VC (Verifiable Credentials) standards; predefined scenario verification rules refer to a series of logical judgment conditions pre-coded in smart contracts. These rules are jointly formulated by medical emergency experts, legal advisors, and system architects according to industry standards and regulations to automatically determine whether the current scenario constitutes a legitimate emergency; the access scope of the emergency data subset refers to the minimum necessary medical data categories that are pre-defined in smart contracts and can be accessed in an emergency. This scope is determined according to medical emergency guidelines, such as including only blood type, allergy history, emergency contacts, etc., rather than all medical records.

[0034] Specifically, when a requester with an authorized device (such as an emergency physician) encounters a patient requiring urgent medical attention, the requester's device application first obtains the target patient's blockchain account address. This process may involve scanning the patient's NFC wristband, a QR code on a medical card, or obtaining it via near-field communication with the patient's permission. The application then packages this patient address along with the requester's own authenticated digital identity stored in the device's secure element, constructing a standardized emergency access request data packet. Next, the application calls the blockchain's interface to initiate a transaction to the known address of a pre-deployed emergency access smart contract, using this data packet as the transaction's payload. Once this transaction is verified by nodes in the blockchain network and packaged into a new block, the smart contract's code is automatically triggered and executed. The smart contract receives the two core parameters—the requester's identity and the patient's address—and stores them in the contract's temporary state variables.

[0035] In some embodiments, when the blockchain account address of the target patient cannot be obtained in special scenarios such as major disasters, a special authorization process based on official disaster events can be executed first to enable secure access to emergency medical data of patients with unknown identities.

[0036] Specifically, firstly, when on-site rescue personnel (i.e., the special requesting party) encounter unidentified casualties, specialized equipment will issue a special emergency access request that does not contain the patient's address but encapsulates an official disaster event identifier. The official disaster event identifier is a unique code uniformly issued and broadcast by emergency management agencies after confirming a large-scale disaster; its format and issuance rules are pre-set according to cross-departmental emergency plans. Upon receiving this special request, an oracle will immediately invoke the authoritative interface of the public safety service system to verify the authenticity and validity of the identifier. Successful verification not only confirms the objective existence of the disaster but also obtains an officially certified special disaster event geofence (i.e., the core geographical area affected by the event) and a special effective time window (i.e., the officially defined start and end times of the emergency response). The value of this is that it defines a spatiotemporally valid trust domain for all subsequent operations, assigning a higher initial trust level to all operations within this domain.

[0037] Secondly, to ensure that unidentified patients can be included in management, the requesting party uses devices equipped with biometric data collection capabilities (such as electrocardiogram monitors and fingerprint scanners) to collect the patient's vital signs in real time on-site. This information, such as an electrocardiogram waveform or a high-resolution iris image, is processed using a hash algorithm (such as SHA-256) to generate a unique, irreversible digital fingerprint. This digital fingerprint is then used as a seed to generate a temporary, special blockchain account address through a deterministic algorithm. This creates a digital identity for anonymous individuals that can be used for on-chain interactions. Although this identity is temporary and anonymous, it is strongly bound to the physical individual through biometrics, ensuring that all subsequent operations accurately correspond to this specific patient. This solves the fundamental obstacle in step S101 where the smart contract could not be started due to the lack of a target address.

[0038] Finally, core evidence, known as the spatiotemporal coexistence fact, is constructed. This is determined by verifying two key pieces of information: the real-time geographic location of the requesting device, and whether the geographic location recorded by the device when collecting the patient's vital signs falls within the aforementioned certified geofence and specific effective time window of the special disaster event. This fact is defined as a mandatory core verification factor. This rule is pre-set in the disaster response logic branch of the smart contract by emergency medical experts and system architects. Its mandatory nature is reflected in the fact that once this factor is satisfied, the conventional multi-factor verification process (such as S102) is bypassed, directly determining the establishment of an emergency and generating a consensus proof. The benefit of this is that it simplifies the decision-making process in extremely chaotic scenarios, ensuring the highest rescue efficiency. As a risk balancing measure, based on the authorization generated through this fast track, access permissions will be strictly limited to a predefined primary emergency data subset. This subset is a minimum necessary dataset, pre-set according to international emergency medical guidelines, containing only the minimum and most critical information such as blood type and allergy history, thus achieving the best balance between saving lives and protecting the privacy of those in the unknown.

[0039] The introduction of this technical step, by constructing a trust model centered on event authentication and dynamically generating temporary on-chain identities bound to biometrics for unknown patients, solves the problem of conventional processes failing due to the inability to identify individuals during major disasters. This enables the technical solution to readily handle two distinct scenarios: individual emergency care and mass disasters, enhancing the system's robustness and practical application value in public health emergency response.

[0040] S102. Obtain identity validity proof from the identity authentication authority based on the authenticated digital identity from the trusted data source outside the chain, generate a geographical location matching result by comparing the geographical location information of the requester's device with the preset medical institution geofence, and obtain the summary of all emergency event records associated with the target patient from the public safety service system to form a scenario verification factor group corresponding to the emergency access request.

[0041] Among them, "off-chain trusted data source" refers to an external information system that exists outside the blockchain system but whose data is accepted by the system as a trusted basis. It usually interacts with the blockchain through oracle technology. "Identity validity certificate" refers to a digital certificate issued by an identity authentication agency (such as the Health Commission or the human resources department of a hospital) to confirm the current professional status of the requester (such as being employed or not having had their license revoked). "Preset medical institution geofence" refers to the virtual geographical boundaries that the system administrator sets in the system for each legitimate medical institution (such as a hospital or emergency center) based on authoritative geographical information. "Geographic location matching result" refers to the Boolean value result generated after comparing the real-time GPS coordinates of the requester's device with the preset geofence, indicating whether it is inside or outside the fence. "Emergency event record summary" refers to the brief information on alarm or request for help events related to the target patient obtained from public safety service systems (such as 110 and 120 emergency call platforms), used to verify the authenticity of the emergency. "Scenario verification factor group" refers to the data set formed by the structured combination of the above-mentioned heterogeneous evidence (identity, location, event) obtained from different dimensions.

[0042] Specifically, the smart contract broadcasts a data request to the off-chain oracle node by triggering an event. This event includes the requester's digital identity and patient information that need to be verified. Upon receiving this event, the oracle node begins executing a series of tasks in parallel or sequentially: it requests the identity verification authority's API with the requester's authenticated digital identity information to verify the identity's validity; simultaneously, it obtains the requester's device's geolocation information submitted with the S101 request or uploaded in real-time via other channels, and performs spatial geometric calculations against the geofence data of medical institutions stored in the system to determine if a match exists; furthermore, the oracle calls the public safety service system's interface, using the patient's identity information (after anonymization) as an index to query for the existence of emergency dispatch or ambulance dispatch records with similar timestamps. The oracle encapsulates the verification results obtained from these three or more sources—identity validity proof (e.g., a digitally signed JSON object), geolocation matching result (a boolean value of true / false), and emergency event record summary (e.g., an event number or summary text)—into a unified contextual verification factor set. Finally, the oracle submits this factor set back to the smart contract via a callback transaction for use in subsequent steps.

[0043] In some embodiments, the acquisition and integration of off-chain data in this step can be achieved in a variety of ways: Optionally, a decentralized oracle network (DON) can be used: the smart contract sends a data request to a decentralized oracle network (such as Chainlink); multiple independent nodes in the network simultaneously obtain data from different data sources (identity API, map service API, public security system API); after these nodes reach a consensus on the obtained data (such as whether the geographical location is within the fence) off-chain, they send the final result after aggregation and signature verification back to the smart contract as a whole context verification factor group.

[0044] It is understandable that other methods can be used to achieve on-chain submission of trusted data, such as using a Trusted Execution Environment (TEE) to ensure the confidentiality and integrity of data during acquisition and processing, which is not limited here.

[0045] S103. Based on the scenario verification rules, if the number of factors that meet the conditions in the scenario verification factor group is greater than or equal to the preset factor number threshold, generate an emergency state consensus proof.

[0046] Among them, the scenario verification rules refer to the logic code embedded in the smart contract, which clarifies how to interpret the scenario verification factor group and the criteria for making a decision; the preset factor number threshold is an integer value set in advance by the system designer based on the trade-off between risk assessment model and emergency response efficiency; the emergency state consensus proof is a verifiable on-chain state or certificate generated after the smart contract internally reaches the conclusion that an emergency state has been established within the context of this system.

[0047] Specifically, after the scenario verification factor set returned in S102 is received by the smart contract, the internal verification logic of the contract is activated. Each factor in the factor set is analyzed one by one, and a judgment is made according to predefined scenario verification rules. These rules may be diverse; for example, "identity validity proof must be true" may be a hard rule, while "geographical location matching" and "existence of emergency event records" may be soft rules that can be selectively satisfied. The core judgment logic is to count the total number of factors in the factor set that are verified as "true" or "meet the conditions." Then, this number is compared with a preset factor quantity threshold. If the number of factors meeting the conditions is greater than or equal to the threshold—for example, in a "choose 2 out of 3" rule, if 2 or 3 factors are confirmed—the smart contract determines that an emergency state is established and immediately generates an emergency state consensus proof. Technically, this proof can be a change in internal state variables (such as isEmergencyVerified=true), or it can be achieved by minting a time-limited non-fungible token (NFT) representing this authorization in the contract and associating it with the request address and the patient's address. Conversely, if the number of factors that meet the conditions is less than the threshold, the emergency state is deemed invalid, the process is terminated, and a failed access attempt is recorded.

[0048] S104. In response to the emergency consensus proof, generate a temporary session key that can only decrypt a subset of emergency data within a preset validity period.

[0049] The preset validity period is a pre-configured time parameter used to define how long the generated key is valid. This parameter is determined by medical guidelines and is designed to ensure that access permissions automatically expire after the emergency ends. The emergency data subset is the patient medical data portion defined in S101 that contains only the most critical emergency information. The temporary session key is a symmetric encryption key (such as an AES-256 key) that is temporarily generated and used specifically for this emergency access session. It is used to decrypt the encrypted and stored emergency data subset and is destroyed or invalidated after the session ends.

[0050] Specifically, once the S103 smart contract successfully generates an emergency consensus proof, it triggers subsequent functions or related logic. The core task of this logic is to generate a highly randomized temporary session key. Key generation can be done on-chain, but for security and efficiency, a better approach is to generate it via an oracle or in a Trusted Execution Environment (TEE). After confirming consensus, the smart contract sends a key generation request with a consensus proof (e.g., a one-time signature authorization) to the key management service. After verifying the request, the key management service generates a high-strength symmetric key. This service also binds a lifecycle to this key, namely the preset validity period defined in S104. This validity period starts counting down from the moment the key is generated. Once the validity period expires, the key can no longer be used for any decryption operations. The sole purpose of this time-limited temporary session key is to decrypt the encrypted emergency data subset corresponding to the target patient, stored in an off-chain database or distributed storage system (such as IPFS).

[0051] In some embodiments, the generation and management of temporary session keys in this step can be achieved in a variety of ways: Optionally, a proxy re-encryption (PRE) technique can be used: a subset of the patient's emergency data is pre-encrypted and stored using the patient's master public key; once the emergency consensus proof is generated, the smart contract authorizes a proxy re-encryption service; this service uses the pre-authorized re-encryption key from the patient to transform the encrypted data into new ciphertext that can be decrypted using the requester's (doctor's) public key, and sets an expiration period policy. In this way, there is no need to generate and transmit new session keys; the requester can directly decrypt the data using their own private key within the expiration period.

[0052] It is understandable that other methods can be used to temporarily authorize keys, such as using attribute-based encryption (ABE) schemes, which use attributes that are verified urgently and serve as decryption strategies within the validity period, without being limited here.

[0053] In some embodiments, to address the high frequency and multiple data access requests that may occur in a single emergency event, after generating the initial emergency state consensus proof, a spatiotemporal trust domain can be constructed and a list-based dynamic authorization mechanism can be adopted. This will improve the authorization efficiency of subsequent accesses and introduce dynamic privacy control capabilities while ensuring security.

[0054] Specifically, this alternative was initiated in response to the initial emergency consensus proof generated by S103, transforming the one-off authorization confirmation into a sustainable and efficient authorization framework. First, the smart contract captures the geographic location information and timestamp contained in the original request that triggered this consensus, and uses this as the core to programmatically define an immutable spatiotemporal trust domain on the blockchain. This trust domain is defined by two core parameters: a preset spatial radius (e.g., pre-set by emergency response experts based on different scenarios such as cities or wilderness) and a preset effective time window (e.g., pre-determined by a medical expert committee according to standard emergency procedures). This materializes the abstract emergency event into a machine-verifiable on-chain entity with clear spatiotemporal boundaries, providing a unified and trusted context for all subsequent automated and efficient authorization operations.

[0055] Simultaneously with the creation of the trust domain, the smart contract immediately performs mapping and recording operations. The blockchain account address of the initial requester is recorded in the newly created temporary authorized rescuer list, and the address of the target patient is recorded in the emergency concern patient list. These two lists are continuously maintained as on-chain states strongly associated with this spacetime trust domain. When other rescuers with verified identities enter this spacetime trust domain and issue a join request, the smart contract automatically verifies the compliance of their geographical location and adds their address to the rescuer list; similarly, other injured individuals discovered at the scene can be added to the patient list. The advantage of this approach is that it shifts from a model of verifying individual requests one by one to a model of maintaining a dynamic list of event participants. Therefore, when an address already in the rescuer list initiates a subsequent valid access request to an address already in the patient list, the smart contract no longer needs to repeat the costly and time-consuming steps of S102 and S103, which involve calling external information sources for multi-factor verification. Instead, only two efficient list inclusion checks need to be performed on-chain. Once the verification is successful, the generation of the subsequent temporary session key is triggered directly, reducing system latency and transaction costs. This is especially true in complex scenarios where multiple rescuers need to continuously monitor and treat the same or multiple patients, where the efficiency advantage is significant.

[0056] This mechanism incorporates a dynamic response capability to patient privacy rights. When a target patient, after regaining consciousness, wishes to assert their privacy control again, they can initiate a specific privacy assertion transaction to the smart contract through their blockchain account. After verifying that the transaction initiator is indeed on the list of patients in urgent need of attention, the contract marks the patient's address as under supervised access. Subsequently, when any rescuer (even if on the authorized list) attempts to access the patient's data again, simple list verification is no longer sufficient to directly trigger key generation; instead, a pending confirmation state is entered, requiring third-party confirmation. This confirmation must be issued by a third party who is also on the temporary authorized rescuer list and has been granted preset supervisory permissions (the granting criteria for these permissions are jointly defined by medical management agencies and legal experts during system design, typically granted to senior doctors or rescue team leaders on-site). Only after the supervisor issues a joint confirmation transaction is a key generated for this supervised access. This mechanism, by introducing a two-person confirmation principle, achieves a smooth transition from prioritizing efficiency to balancing privacy and security in the later stages of an emergency.

[0057] Finally, when the preset effective time window expires, the spatiotemporal trust domain automatically becomes invalid. The smart contract will permanently terminate all permissions triggered by key generation based on the aforementioned list states, and archive the final member lists of the temporary authorized rescuer list and the emergency concern patient list, along with all access logs that occurred during this period, as a whole in an immutable manner. This ensures the strict temporality of emergency access permissions and provides a complete and highly credible chain of evidence for subsequent accountability, medical process review, and compliance audits.

[0058] The above steps transform the one-time high-cost verification into an efficient and sustainable authorization framework by constructing a spatiotemporal trust domain and a dynamic management list. The core advantage is that by sacrificing the minimal time of the initial verification, it achieves millisecond-level table lookup authorization for countless subsequent access requests, thereby solving the system bottleneck and inefficiency caused by repeated verification in continuous group rescue, and achieving a balance between rescue efficiency and dynamic privacy protection.

[0059] S105. Send the temporary session key to the requester and record the emergency access request, scenario verification factor, and emergency state consensus proof on the blockchain in the form of an immutable transaction.

[0060] Here, blockchain refers to the underlying distributed ledger platform that supports the operation of this method; an immutable transaction is a transaction record that, once written into the blockchain and confirmed by a sufficient number of blocks, cannot be modified or deleted by any single party; the act of recording refers to permanently storing key information as part of a transaction or the log / event generated by the transaction on the blockchain for subsequent auditing and traceability.

[0061] Specifically, this step involves two parallel actions: functional key delivery and auditable on-chain recording. After generating a temporary session key in S104, this key is delivered to the requesting application via a secure off-chain channel. This is typically achieved through end-to-end encrypted communication. For example, a key management service encrypts the session key using the public key contained in the requester's digital identity and then pushes it to the requester's device via a secure protocol such as HTTPS. The device then decrypts the session key using its own private key. Once the requester receives the key, it can request the ciphertext of a subset of emergency data from the server storing the encrypted data and decrypt it locally to view the patient's critical medical information. Simultaneously, to ensure the transparency, traceability, and non-repudiation of the entire process, the smart contract initiates a final transaction. The content of this transaction, or the resulting event log, will contain all the key metadata of this emergency access: the original emergency access request (including the requester ID, patient address, and timestamp), a summary of the scenario validation factor set used for decision-making (or a pointer to its on-chain storage location), and the finally generated emergency consensus proof itself. Once the transaction is packaged into a block, it forms a permanent, public (to the authorizing party), and tamper-proof audit log, providing irrefutable evidence for any subsequent disputes, reviews, or compliance checks.

[0062] In some embodiments, the recording of uplinking and key transmission in this step can be achieved in a variety of ways: Optional, state variable storage and secure envelope encapsulation: The smart contract stores all audit information for this access in a structured state variable of mapping or array type, and all records are directly stored in the on-chain state; the key management service packages the temporary session key together with information such as validity period and access policy into a digital envelope; this envelope is encrypted and sent to the requester, and the requester application can only open the envelope to obtain the key after verifying the envelope signature and meeting local security conditions.

[0063] It is understandable that other methods can be used to achieve the coordination of audit log and key delivery, such as packaging the on-chain hash of the audit log together with the session key to ensure that the key is strongly associated with a specific, auditable access, which is not limited here.

[0064] In the above embodiments, a scenario verification factor group is introduced, with smart contracts as the core of execution, to comprehensively evaluate multi-dimensional information such as identity, geographical location, and public event records. This threshold judgment mechanism based on multi-source evidence enables authorization decisions to be automated and respond quickly to real emergency scenarios. Simultaneously, the generation of temporary session keys limits the scope and timeliness of access, and the use of immutable on-chain records ensures post-event traceability, thus achieving a balance between the immediacy of data access and patient privacy security during rescue operations.

[0065] In other embodiments of this application, in emergency situations, when a legitimate requester is isolated and without support, or their professional team has not yet arrived, resulting in an inability to find a sufficient number of neighboring nodes for mutual verification, they may be incorrectly excluded by the authentication system due to the inability to accumulate effective mutual trust scores. The blockchain-based medical data privacy protection and sharing method provided in this application can activate social relationship factor analysis based on blockchain history, using verification of past on-chain interactions with patients as an alternative authentication basis to ensure that independent rescuers can also obtain authorization.

[0066] like Figure 2 The diagram shown is another flowchart illustrating a blockchain-based method for protecting and sharing medical data privacy, as provided in this application embodiment. The method includes the following steps: S201. Upon receiving an emergency access request, the pre-deployed emergency access smart contract is invoked based on the target patient's blockchain account address.

[0067] S202. Obtain identity validity proof from the identity authentication authority based on the authenticated digital identity from the trusted data source outside the chain, generate a geographical location matching result by comparing the geographical location information of the requester's device with the preset medical institution geofence, and obtain the summary of all emergency event records associated with the target patient from the public safety service system to form a scenario verification factor group corresponding to the emergency access request.

[0068] Steps S201-S202 and Figure 1 Steps S101-S102 in the illustrated embodiment are similar and can be found in the descriptions of steps S101-S102, which will not be repeated here.

[0069] In some embodiments, when all preset off-chain trusted data sources are inaccessible due to network interruption or service crash, an alternative verification factor generation mechanism based entirely on on-chain historical data can be activated, thereby enabling the construction of effective authentication evidence even in the context of information silos.

[0070] Specifically, the execution occurs when, after attempting to call all pre-set trusted off-chain data sources (such as identity authentication authorities, public safety service systems, etc.), consecutive error responses such as timeouts, connection failures, or service unavailability are received, and the pre-set retry strategy (e.g., exponential backoff retries) still fails. At this point, the external environment is determined to be unreliable, and all further external API calls are immediately suspended to avoid resource waste and process blockage, while automatically switching to on-chain self-verification mode. In this mode, the on-chain data analysis engine is activated, which directly parses all historical transaction records of the target patient's blockchain account. This process is accomplished by querying local or still accessible full blockchain nodes, without relying on any external, non-blockchain-native services. The core task of the analysis engine is to search the patient's list of counterparties for evidence of a strong correlation with the current emergency access requester's certified digital identity (i.e., its blockchain address). Here, a strong correlation is quantified as the existence of more than a pre-set number of interaction records between the two parties. This preset number of transactions is a threshold set by risk control experts and data scientists by analyzing common patterns in the on-chain social graph. The purpose is to filter out accidental, one-off transactions and select interactions with stable and repetitive characteristics. In the real world, such relationships often correspond to family doctors, long-term contracted specialists, or regularly visited community health service centers.

[0071] Once the analysis engine identifies one or more matching counterparties in the patient's transaction history, it encapsulates the fact that there is a common counterparty with more than five historical transaction records with the requester into a social relationship factor. This social relationship factor is essentially a verifiable digital proof of acquaintance based on cryptographic history. While not as authoritative as official identity verification, it becomes highly valuable and credible circumstantial evidence in the event of complete loss of external information. Subsequently, this newly generated, purely endogenous social relationship factor is used to reconstruct the scenario verification factor set. The original factor set, empty due to data source failure, is now replaced by this reconstructed scenario verification factor set containing the social relationship factor. This means that subsequent verification processes (such as S203) will no longer rely on external identity or event information, but will continue based on this newly constructed on-chain evidence proving a possible existing connection between the requester and the patient, thus allowing the authentication process to continue even in extremely challenging environments.

[0072] The aforementioned technical steps, by using the blockchain's immutable transaction history as the ultimate, externally independent source of fact, enable the extraction of credible social relationship evidence from on-chain data to replace invalid verification factors in the worst-case scenario where all regular communication and external services fail. This frees the emergency access authorization process from absolute dependence on external networks, ensuring operational capability even in disaster scenarios such as city-wide communication outages.

[0073] S203. Monitor all emergency access requests within a preset time and space window. When the number of emergency access requests originating from a unified preset geofence exceeds the threshold for mass events, stop calling external data sources and broadcast a request to all requesters' certified digital identities for a cryptographic challenge task involving near-field peer-to-peer authentication.

[0074] The preset time-space window refers to a specific time and spatial range defined in advance by the system and continuously sliding to count request density, such as "within the last 5 minutes" and "within the same preset geofence". The preset geofence is used to represent a geographical area with clear boundaries pre-delineated by urban planning or emergency management departments, such as a community, venue, or transportation hub. The mass incident threshold is a numerical parameter, pre-set by emergency management experts based on historical data and simulations, used to distinguish between routine sporadic emergency rescue and large-scale emergencies, such as being set as "more than 20 emergency access requests received within 5 minutes within the same geofence". "; Suspending calls to external data sources refers to the system actively suspending the process of initiating data requests to external APIs such as public safety service systems through the oracles in S202 after determining that it has entered a mass event mode; Near-field peer-to-peer node mutual verification represents a decentralized trust establishment mechanism that does not rely on external centralized facilities, that is, allowing participants (nodes) in physical proximity to prove each other's presence and identity through direct communication; Cryptographic challenge tasks are computational tasks issued by the system that require two or more devices to cooperate through near-field communication to complete, with the aim of confirming the physical proximity of these devices at the same time through cryptographic means.

[0075] Specifically, under normal urban operation, emergency requests are low-probability and geographically dispersed. However, in the event of a mass incident such as an earthquake, terrorist attack, or large-scale accident, the system will receive a large number of requests from different rescue personnel within a very small time window (e.g., within the same block, within a few minutes). The background monitoring module will accumulate the number of these requests in real time and compare them with a preset mass incident threshold. Once the number of requests exceeds the threshold, it is determined that the current situation has exceeded the normal emergency response capacity, and centralized data sources such as external authentication and event queries may have become unreliable or slow to respond due to network congestion, service overload, or physical damage. Therefore, two actions are taken: first, the S202 process is suspended to avoid delays in rescue due to waiting for unreliable external data; second, a mode switching instruction containing a cryptographic challenge is broadcast to all requesting devices located within the geofence of the hotspot. The design principle of this mission is to prove the existence of a cluster. It requires rescuers' devices to use near-field technologies such as Bluetooth (BLE), Wi-Fi Direct, or Near Field Communication (NFC) to find other rescue devices in the vicinity that have also received the mission, and jointly complete a cryptographic proof that requires the private keys of both parties to be signed. In this way, a trusted network based on physical proximity can be established from the ground up without a centralized authority.

[0076] S204. Receive the neighbor verification beacon returned by the requesting device and cross-verify the validity of the geographical coordinates, timestamps and signatures of both parties encapsulated in the neighbor verification beacon.

[0077] Among them, the neighboring mutual verification beacon refers to the structured data packet jointly generated by two neighboring requesting devices after completing the cryptographic challenge task in S203. It is a cryptographic proof generated after the requesting devices complete the challenge task through near-field communication. Cross-validation represents a verification strategy that compares multi-source information. It not only independently verifies the validity of each beacon, but also compares the correlation information between different beacons to enhance the overall credibility.

[0078] Specifically, the device transmits these beacons back to the blockchain system (usually submitted to an oracle or a specific on-chain contract) via an available network connection (such as mobile data or satellite communication). Upon receiving these beacons, the system backend initiates a verification process. For each received beacon, the verification process first performs basic integrity and validity checks: First, signature verification, extracting the blockchain account addresses of the two claiming requesters (e.g., A and B) from the beacon and obtaining the corresponding public keys from their certified digital identities. Then, public key A is used to verify whether signature A is indeed a valid signature of the beacon content (excluding the signature itself), and similarly, signature B is verified to ensure that the beacon was indeed signed by these two entities and that no one impersonated them. Second, spatiotemporal verification, checking whether the timestamp encapsulated in the beacon is within the valid time window of the current mass event and whether the geographical coordinates fall within the preset geofence that triggered the event. Only beacons that pass all the above basic checks are considered initially valid. Furthermore, cross-validation logic is triggered to check for the existence of beacons generated by B and A with mirror-symmetric content; such two-way confirmed beacon pairs have higher credibility. At the same time, a temporary mutual verification relationship graph is constructed to check for contradictions. For example, if the beacons generated by A and B show that they are at location X, while the beacons generated by A and C show that A is at location Y at the same time, such contradictory beacons will be marked as low credibility or directly invalidated.

[0079] In some embodiments, the submission and verification of the beacon in this step can be achieved in a variety of ways: Optionally, on-chain smart contract verification can be used: the requesting device uses the generated proximity verification beacon as input data to call a dedicated verification smart contract; the smart contract implements cryptographic primitives such as ecrecover, which can directly recover the signer's address on-chain and compare it with the address declared in the beacon to complete signature verification; the contract also reads the current block timestamp and geofence data stored in the contract to complete spatiotemporal verification. After successful verification, the contract will trigger a "beacon verification successful" event.

[0080] S205. Establish temporary mutual trust scores for all requesters within the domain, and accumulate them based on the number of times the signer appears in different neighboring mutual verification beacons that have been successfully verified.

[0081] The temporary mutual trust score is a numerical score dynamically created for this mass incident to quantify the credibility of each requester in this incident; the scoring rules are defined by the number of times the signer appears in different neighboring mutual verification beacons that have been successfully verified, that is, a requester's score is equal to the number of times they have successfully participated in and completed near-field mutual verification that has been confirmed as valid in S204.

[0082] Specifically, the smart contract or backend service maintains a temporary, scoreboard-like data structure for this mass event. This is typically a mapping where the key is the requester's blockchain account address, and the value is the corresponding mutual trust score. Whenever S204 successfully verifies a neighboring mutual verification beacon (assuming it's generated by requester A and requester B), a score accumulation operation is automatically performed. The entries for A and B in the mapping are found, and their respective scores are incremented by one. For example, if A's initial score is 0, after successfully verifying with B, their score becomes 1. Subsequently, if A successfully verifies with C, their score accumulates to 2. The theory is a simplified model of trust in social networks: in a closed, real-world physical environment, a person's credibility can be indirectly measured by how many other trusted members see and confirm them.

[0083] In some embodiments, the scoring mechanism in this step can be implemented in a variety of ways: Optionally, a more complex scoring model can be introduced, incorporating weights and decay factors. This results in more complex scoring rules. For example, mutual verification with a high-reputation node that has already achieved a high score can yield a higher score bonus (weight). To prevent the unlimited exploitation of early accumulated scores, a time decay factor can be introduced, where scores gradually decrease over time, encouraging rescuers to continuously verify each other to maintain their trust level. Smart contracts need to maintain more complex data structures, such as recording the timestamp of each verification and recalculating the current valid score based on a preset decay function each time scoring occurs.

[0084] It is understandable that other methods can be used to quantify mutual trust, such as using an algorithm similar to PageRank to iteratively calculate the centrality of each node in the mutual trust graph as its trust score, which is not limited here.

[0085] In some embodiments, in addition to authentication through individual scoring, a graph theory-based trust cluster analysis method can be introduced to achieve a leap from authenticating individual rescuers to authenticating the entire collaborative rescue unit in batches, thereby improving the authorization efficiency in large-scale, organized rescue scenarios.

[0086] Specifically, all neighboring mutual verification beacons successfully verified in S204 are considered edges connecting rescue personnel, and all requester addresses participating in mutual verification are considered nodes, thus logically constructing a dynamically evolving trust relationship topology. Periodically, or whenever the graph structure changes, a graph clustering algorithm (such as community detection algorithms like Louvain Modularity or Girvan-Newman) is applied to this topology to automatically identify trust clusters within the graph. A trust cluster is defined as a subset of nodes where the connections between internal nodes are significantly stronger than their connections to external nodes. This strength is quantified by two parameters jointly preset by cybersecurity and emergency management experts: a preset internal density threshold and a preset external density threshold. A subset is considered a qualified trust cluster only if its internal connection density (the ratio of the number of edges within the cluster to the maximum possible number of edges within the cluster) is higher than the internal threshold, and its connection density to nodes outside the cluster is lower than the external threshold. The advantage of this approach is that it allows for the mathematical identification of groups or teams that are actually working closely together and frequently verifying each other from a mixed pool of on-site personnel.

[0087] Once several trust clusters are identified, each cluster is independently quantitatively evaluated to calculate the overall trustworthiness. The evaluation, based on cluster trustworthiness, is obtained by multiplying two key dimensions. The first dimension is cluster size, which is the total number of independent requesting nodes within the trust cluster, directly reflecting the size of the team. The second dimension is cluster mutual authentication completeness, used to measure the tightness of collaboration within the team. It is calculated by dividing the total number of beacons successfully authenticated between cluster members by the theoretically maximum number of mutual authentications possible within the cluster (i.e., cluster size n multiplied by n-1, since mutual authentication between A and B and between B and A are considered two independent signature actions). This ratio is between 0 and 1; the closer it is to 1, the more likely that all members within the team have completed mutual authentication, indicating an extremely strong internal trust foundation. Multiplying the cluster size by the completeness yields a cluster trustworthiness that balances both the number of members and their unity of purpose, effectively preventing fake clusters formed by a few malicious nodes manipulating scores. Finally, when the cluster credibility calculated by a certain trust cluster exceeds the cluster authentication threshold preset by the highest decision-making body, representing an extremely high level of trust, the cluster is no longer waited for its individual members to reach the required score; instead, the entire trust cluster is directly recognized as a trusted rescue unit. In response to this overall authentication, the smart contract immediately generates emergency consensus proofs in batches for all requesting members within the trusted rescue unit, granting them access to emergency data.

[0088] The above steps elevate the authentication perspective from isolated individuals to a collaborative group. By identifying highly trusting rescue clusters, judgments can be made based on collective reputation, accelerating the overall authorization process for professional rescue teams (such as fire departments and medical teams). This is because members naturally and quickly complete internal mutual verification on-site, rapidly forming highly credible trust clusters. This approach achieves an efficiency improvement from activating individuals one by one to activating entire areas.

[0089] S206. Once the mutual trust score of the requesting party reaches the preset group consensus threshold, an emergency state consensus proof is generated for the corresponding requesting party.

[0090] In this context, the mutual trust score of the requesters refers to the trust score dynamically calculated and accumulated for each requester in S205; the preset group consensus threshold is a decision threshold value, which is pre-set by security experts and emergency managers based on a risk assessment model, representing the minimum score requirement for a requester to be considered to have accumulated enough peer mutual verification, thus being trusted and granted access; generating an emergency state consensus proof for the corresponding requester means that once a requester's score reaches the threshold, an on-chain authorization certificate with the same effect as in S103 is generated separately, marking that the individual has passed the special authentication in the scenario of a mass event.

[0091] Specifically, in S205, when a requester's (e.g., requester A) mutual trust score is updated, the smart contract immediately performs a conditional check: it checks whether requester A's current score is greater than or equal to a preset group consensus threshold. If the score has not yet reached the threshold, the process ends, waiting for the next score update; if the score reaches or exceeds the threshold, it is determined that the requester has obtained sufficient decentralized consensus within the on-site rescue group, and their identity and presence intention are considered trustworthy. At this point, the smart contract generates an emergency state consensus proof for requester A. Technically, this proof can be implemented by minting a time-limited access authorization NFT to requester A's address, or by marking requester A's address as authorized in a mapping that specifically records authorization status. This process is atomic, meaning that scoring and authorization judgment are completed in the same transaction, ensuring state consistency. This mechanism is an asynchronous achievement process: on-site rescuers reach the consensus threshold and obtain authorization sequentially and independently based on their respective mutual verification activities, without waiting for everyone to be ready, thus achieving a streamlined and highly efficient authentication process.

[0092] S207. In response to the emergency state consensus proof, generate a temporary session key that can only decrypt a subset of emergency data within a preset validity period.

[0093] S208. Send the temporary session key to the requester and record the emergency access request, scenario verification factor, and emergency state consensus proof on the blockchain in the form of an immutable transaction.

[0094] Steps S207-S208 and Figure 1 Steps S104-S105 in the illustrated embodiment are similar and can be found in the descriptions of steps S104-S105, which will not be repeated here.

[0095] In the above embodiments, by monitoring the density of emergency requests to identify mass events and suspending calls to external data sources, system paralysis is avoided when external services fail. Next, a cryptographic challenge for near-field peer-to-peer authentication is initiated, shifting the authentication basis from unreliable remote servers to verifiable physical proximity. By converting the authentication results into an accumulative mutual trust score, the collective testimony of on-site personnel is quantified into individual credibility. Finally, when the score reaches a consensus threshold, an emergency consensus proof is granted, thus constructing a self-certifying trust system without a centralized authority. This ensures that even in extreme disaster scenarios such as communication interruptions, emergency access authorization can still be reliably conducted based on cryptography and physical reality, improving availability while balancing efficiency and security.

[0096] The following describes an exemplary medical data privacy protection and sharing system 300 provided in an embodiment of this application. Figure 3 This is an exemplary hardware structure diagram of the medical data privacy protection and sharing system 300 provided in the embodiments of this application.

[0097] In some embodiments, the medical data privacy protection and sharing system 300 is a computer device or includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

[0098] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0099] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0100] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0101] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0102] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A blockchain-based method for protecting and sharing medical data privacy, characterized in that, include: Upon receiving an emergency access request, the pre-deployed emergency access smart contract is invoked based on the target patient's blockchain account address. The emergency access request includes the requester's authenticated digital identity and the target patient's blockchain account address; The emergency access smart contract predefines scenario verification rules and the access scope of emergency data subsets. From the trusted data source outside the chain, based on the certified digital identity, the identity validity certificate is obtained from the identity authentication authority; the geographical location information of the requester's device is compared with the preset medical institution geofence to generate a geographical location matching result; and the summary of all emergency event records associated with the target patient is obtained from the public safety service system to form a scenario verification factor group corresponding to the emergency access request. According to the scenario verification rules, if the number of factors that meet the conditions in the scenario verification factor group is greater than or equal to the preset factor number threshold, an emergency state consensus proof is generated. In response to the emergency state consensus proof, a temporary session key is generated that can only decrypt the emergency data subset within a preset validity period; The temporary session key is sent to the requester, and the emergency access request, the scenario verification factor, and the emergency state consensus proof are recorded on the blockchain in the form of an immutable transaction.

2. The method according to claim 1, characterized in that, The step of generating a temporary session key in response to the emergency state consensus proof, which can only decrypt the emergency data subset within a preset validity period, specifically includes: In response to the emergency state consensus proof, based on the geographical location information and the timestamp corresponding to the emergency event request, a spatiotemporal trust domain with a preset spatial radius and an effective time window, which is tamper-proof, is defined on the blockchain. The blockchain account addresses of rescuers and patients within the spatiotemporal trust domain are mapped and recorded as a list of temporarily authorized rescuers and a list of patients in urgent need of attention, and the list of temporarily authorized rescuers and the list of patients in urgent need of attention are maintained as on-chain states associated with the spatiotemporal trust domain. In response to a valid access request originating from an address in the list of temporarily authorized rescuers and pointing to an address in the list of patients in urgent need of attention, the system verifies that the requester's address exists in the list of temporarily authorized rescuers and that the target patient's address exists in the list of patients in urgent need of attention. This replaces the step of repeatedly performing the emergency consensus proof on the access request, and triggers the generation of a temporary session key based on the verification result. After the expiration of the effective time window of the spatiotemporal trust domain, the permission to generate the key based on the list status is terminated, and the final status of the temporary authorized rescuer list and the emergency concern patient list, along with all access logs, are archived as audit records in an immutable manner.

3. The method according to claim 2, characterized in that, The step of verifying that the requester's address exists in the list of temporarily authorized rescuers and that the target patient's address exists in the list of patients of urgent concern replaces the step of repeatedly performing the emergency consensus proof on the access request, and triggers the generation of a temporary session key based on the verification result, specifically including: When an on-chain transaction expressing a privacy claim is received from the target patient, the account address of the corresponding target patient in the list of patients in urgent need of attention is marked as a supervised access status. By verifying that the requester's address exists in the list of temporary authorized rescuers, that the target patient's address exists in the list of patients in urgent need of attention, and determining whether the target patient's address is in the conditional access state; If so, after obtaining the third-party confirmation information, the generation of a temporary session key is triggered; the third-party confirmation information is a joint confirmation information issued by a third party with preset supervision authority that exists in the list of temporary authorized rescuers.

4. The method according to claim 1, characterized in that, According to the scenario verification rules, when the number of factors satisfying the conditions in the scenario verification factor group is greater than or equal to a preset factor number threshold, an emergency state consensus proof is generated, specifically including: Monitor all emergency access requests within a preset time and space window. When the number of emergency access requests originating from a unified preset geofence exceeds the threshold for mass events, stop calling external data sources and broadcast a request to all requesters' authenticated digital identities for a cryptographic challenge task involving near-field peer-to-peer mutual authentication. Receive the proximity verification beacon returned by the requesting device, and cross-verify the validity of the geographic coordinates, timestamp, and signatures of both parties encapsulated in the proximity verification beacon; the beacon is a cryptographic proof generated by the requesting devices after completing the challenge task through near-field communication; Temporary mutual trust scores are established for all requesters within the domain, and are accumulated based on the number of times the signer appears in different successfully verified neighboring mutual verification beacons. Once the mutual trust score of the requesting parties reaches the preset group consensus threshold, an emergency state consensus proof is generated for the corresponding requesting party.

5. The method according to claim 4, characterized in that, After establishing temporary mutual trust scores for all requesters within the domain, and accumulating the scores based on the number of times the signer appears in different successfully verified neighboring mutual verification beacons, the method further includes: Analyze the trust relationship topology graph formed by all verified neighboring mutual verification beacons, and use graph clustering algorithm to identify trust clusters among the internal nodes; the trust cluster is a subset of nodes whose connection density is greater than a preset internal density threshold and whose inter-cluster connection density with other nodes in the topology graph is less than a preset external density threshold. For each trusted cluster, the cluster size and intra-cluster mutual verification completeness are calculated independently, and the cluster credibility is generated by combining the cluster size and the intra-cluster mutual verification completeness; the cluster size is the total number of independent requester nodes contained in the trusted cluster; the intra-cluster mutual verification completeness is the ratio of the total number of neighboring mutual verification beacons that have been successfully verified and whose signer and signee both belong to the same trusted cluster, to the cluster size multiplied by the corresponding cluster size minus 1; the cluster credibility is the product of the cluster size and the intra-cluster mutual verification completeness. When the trustworthiness of a trusted cluster exceeds a preset cluster authentication threshold, the corresponding trusted cluster will be used as a trusted rescue unit. In response to the overall authentication of the trusted rescue unit, an emergency state consensus proof is generated for all member requesters within the trusted rescue unit.

6. The method according to claim 1, characterized in that, The process involves obtaining identity validity proof from an identity authentication authority based on the authenticated digital identity from an off-chain trusted data source, generating a geographical location matching result by comparing the requester's device's geographical location information with a preset medical institution geofence, and obtaining summaries of all emergency event records associated with the target patient from a public safety service system. These elements form a scenario verification factor set corresponding to the emergency access request, specifically including: After all the pre-set off-chain trusted data sources fail to be called in succession, the external call is stopped, and by parsing the historical transaction records of the target patient's blockchain account, the counterparty with the certified digital identity of the requester has a preset number of interaction records and is identified and adopted as social relationship factor. The scenario validation factor set is reconstructed based on the alternative factors to obtain the reconstructed scenario validation factor set.

7. The method according to claim 1, characterized in that, Before invoking the pre-deployed emergency access smart contract based on the target patient's blockchain account address after receiving an emergency access request, the process also includes: In response to receiving a special emergency access request containing an official disaster event identifier but with a missing target patient's blockchain account address, the public safety service system is invoked to verify the disaster event identifier and obtain the certified special disaster event geofence and special effective time window. Based on the biometric information collected in real time on-site by the special requester, a temporary special blockchain account address is generated, and the temporary special blockchain account address is used to replace the blockchain account address to initiate the emergency access smart contract. The fact that both the requester's device geographic location information and the geographic location information recorded when collecting the biometric information are located within the geofence and special effective time window of the special disaster event are used as a mandatory core verification factor. Based on the satisfaction of the mandatory core verification factors, an emergency consensus proof is generated, and access is authorized only to a predefined subset of primary emergency medical data.

8. A medical data privacy protection and sharing system, characterized in that, The medical data privacy protection and sharing system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the medical data privacy protection and sharing system to perform the method as described in any one of claims 1-7.

9. A computer program product containing instructions, characterized in that, When the computer program product is run on the medical data privacy protection and sharing system, the medical data privacy protection and sharing system performs the method as described in any one of claims 1-7.

10. A computer-readable storage medium comprising instructions, characterized in that, When the instructions are executed on the medical data privacy protection and sharing system, the medical data privacy protection and sharing system performs the method as described in any one of claims 1-7.

Images