Blockchain-based gynecological and obstetric emergency medical data security sharing system

Abstract

The application discloses a gynecological emergency medical data security sharing system based on a blockchain, and relates to the technical field of medical information processing. The system is used to solve the security and timeliness of multi-institution data sharing in emergency scenarios. First, the data hierarchical desensitization module processes and desensitizes patient personal identifiers and medical data, and outputs safe sharing data. Then, the on-chain evidence storage module processes the continuous monitoring data stream in windows, extracts key physiological characteristics, generates characteristic value hashes, constructs data feature descriptors, and submits them to the blockchain network. The emergency access token management module realizes dynamic authorization through a smart contract, generates temporary access tokens associated with data feature descriptors. Finally, the secure decryption and data sharing module verifies permissions based on hierarchical decryption keys, decrypts data, and compares characteristic value hashes to ensure data integrity, shares data with authorized parties, and records operation logs, realizing efficient, secure, and traceable data sharing.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of medical information processing, in particular to an obstetrics and gynecology emergency medical data security sharing system based on a blockchain. BACKGROUND

[0002] With the increasing demand for treatment of obstetrics and gynecology emergency and critical cases, a large amount of real-time maternal and infant vital sign data, monitoring records and emergency treatment information are generated in the clinical environment. How to realize efficient sharing and rapid calling among multiple institutions while ensuring patient privacy and data security has become an important problem to improve emergency efficiency and reduce maternal and infant risks. Traditional medical data exchange methods mostly rely on centralized platforms or point-to-point transmission, which not only has the risk of interception and tampering in the transmission link, but also is difficult to trace the use process of the data completely, and cannot meet the dual requirements of timeliness and security in emergency scenarios.

[0003] For example, the Chinese invention patent with publication number CN119580911B discloses a data security sharing method, system and device. The method includes: a doctor establishes an EMR for a patient, the doctor encrypts the generated EMR using the patient's public key, and stores the EMR ciphertext on a cloud server; the blockchain stores the patient's EMR keyword, hash value, log and other information, provides a retrieval service using the keyword, returns the EMR hash value and index, and uses an inverted index-based blockchain ciphertext retrieval method to retrieve the EMR ciphertext on the cloud server. The method realizes efficient ciphertext retrieval, thereby comprehensively improving the deficiencies of the existing electronic medical record system in terms of data sharing, efficiency and security.

[0004] However, this kind of method still has some substantial shortcomings in obstetrics and gynecology emergency applications: first, the medical record data adopts a whole encryption and whole decryption processing mode, which will cause a long data calling process in the emergency treatment scenario, and cannot guarantee that the information can be quickly retrieved to support real-time decision-making; second, the ciphertext retrieval process mainly relies on keyword indexing, which is difficult to differentiate between different types of medical data, and doctors are often forced to decrypt irrelevant content when accessing data, thereby increasing the possibility of privacy leakage; finally, the access control mechanism is designed as a fixed process, which is slow in responding to sudden treatment requests, and the authorization link is prone to delay, affecting the immediate availability of emergency data. SUMMARY

[0005] In view of the deficiencies of the prior art, the present application provides an obstetrics and gynecology emergency medical data security sharing system based on a blockchain, which solves the problems of the above background art.

[0006] To achieve the above object, the present application is realized by the following technical scheme: the gynecological emergency medical data security sharing system based on blockchain includes the following modules: a data hierarchical desensitization module, which is used to establish a multi-level desensitization rule according to the sensitivity difference of gynecological emergency data, and to perform desensitization and replacement processing on the patient's personal identifier according to the multi-level sensitivity rule, while performing hierarchical identification on the medical data itself, and outputting the gynecological emergency medical data after hierarchical desensitization; an on-chain evidence storage module, which is used to receive desensitized emergency data with hierarchical identification, perform window processing on the continuously generated monitoring data stream, extract the key physiological feature value in each time window and calculate its feature value hash, combine the feature value hash with the data hierarchical identification to generate a data feature descriptor, and submit the hash value of the descriptor as a storage transaction to the blockchain network; an emergency access token management module, which is used to receive the emergency access request of the emergency doctor through the smart contract deployed on the blockchain, initiate a notification to the patient's preset proxy decision maker and start a timer, and generate a temporary access token associated with the data feature descriptor hash value after obtaining the proxy voting consent in accordance with the preset rule; a secure decryption and data sharing module, which is used to verify the access authority of the requestor and the validity of the temporary access token and generate a hierarchical decryption key, retrieve the corresponding ciphertext data in the distributed storage system according to the data feature descriptor obtained from the blockchain, perform decryption operation through the hierarchical decryption key, recalculate the feature value hash of the decrypted data and compare it with the original feature value hash stored on the blockchain, and share the data with the authorized party and record the operation log after verification.

[0007] Further, the establishment logic of the multi-level desensitization rule according to the sensitivity difference of the gynecological emergency data is as follows: different data types in the gynecological emergency data are identified, and the data is divided into four categories: personal identifier, quasi identifier, sensitive medical data and general medical data; according to the order of data sensitivity from high to low, the personal identifier is defined as the first sensitivity level, the quasi identifier is defined as the second sensitivity level, the sensitive medical data is defined as the third sensitivity level, and the general medical data is defined as the fourth sensitivity level; each sensitivity level is configured with corresponding desensitization processing strength, wherein the first sensitivity level is configured with irreversible replacement processing of hash algorithm, the second sensitivity level is configured with format reservation encryption processing, the third sensitivity level is configured with numerical intervalization processing based on a preset threshold range, and the fourth sensitivity level is configured with minimal processing based on key field removal, a mapping relationship between the sensitivity level and the desensitization processing strength is established, and a multi-level desensitization rule system is formed.

[0008] Furthermore, based on multi-level sensitivity rules, the patient's personal identifier is anonymized and replaced. Simultaneously, the medical data itself is categorized and labeled. The specific process for outputting graded anonymized obstetric and gynecological emergency medical data is as follows: Personal identifiers at the first sensitivity level are hashed to generate pseudonyms; quasi-identifiers at the second sensitivity level are processed using the AES encryption algorithm while maintaining their original data format characteristics; sensitive medical data at the third sensitivity level undergoes numerical range conversion; and general medical data at the fourth sensitivity level undergoes identifier removal. Sensitivity level labels are added to each processed obstetric and gynecological emergency data element. The processed data elements are repackaged according to the emergency event timeline. Metadata containing generation timestamps and processing institution information is added to the data packet. The complete data packet is signed and verified using an asymmetric key digital signature algorithm, outputting graded anonymized obstetric and gynecological emergency medical data.

[0009] Furthermore, the specific process of receiving desensitized emergency data with graded labels, performing windowing processing on the continuously generated monitoring data stream, extracting key physiological characteristic values ​​within each time window, and calculating their characteristic value hashes is as follows: An adaptive time window length is set based on the clinical characteristics of the obstetric and gynecological emergency monitoring data. The continuously generated vital sign data stream is segmented into equal-length segments. Key physiological parameters reflecting maternal and infant safety status are extracted within each time window, including fetal heart rate variability, uterine contraction pressure curve morphology, and maternal circulatory function indicators. The original sampled data is filtered using a weighted moving average algorithm to suppress measurement noise interference. Statistical characteristic quantities of the characteristic parameters within each time window are calculated, including trend change rate, abnormal fluctuation amplitude, and stable interval range. The statistical characteristic quantities are paired and combined with the time window label information to construct a multi-dimensional feature vector. After normalization, an irreversible characteristic value hash is generated using a hash algorithm.

[0010] Furthermore, the specific process of combining feature value hashes with data hierarchical identifiers to generate data feature descriptors, and submitting the hash value of this descriptor as a notarization transaction to the blockchain network is as follows: A mapping table between feature value hashes and corresponding data hierarchical identifiers is established, and timestamp sequences and data type classification information are added; the combined information is structurally encapsulated using TLV format, where the type field identifies the data type, the length field records the data size, and the value field stores the specific content; version control information and integrity check codes are added to the descriptor to generate a standardized data feature descriptor; after serialization encoding of the descriptor, a unique content identifier is generated through hash operation; the content identifier is bound to the storage path information of the original data to construct a complete notarization transaction message; a notarization request is submitted through the transaction interface of the blockchain node, and the key information of the feature descriptor is written into the distributed ledger.

[0011] Further, the emergency access token management module comprises the following steps: receiving an emergency access request submitted by an emergency doctor through an intelligent contract interface deployed on the blockchain, the request containing a doctor identity credential, a patient medical record identifier, and a data feature descriptor hash value of the requested access; after verifying the legality of the doctor's identity, sending an access authorization request notification to at least two proxy decision makers preset for the patient, and starting a configurable timer to set a voting decision time window; collecting and verifying the digital signature voting responses of the proxy decision makers in real time through the voting of the intelligent contract, and when the consent votes that meet the preset multi-signature rule are obtained before the timer expires, generating a time-limited temporary access token, binding the temporary access token with the data feature descriptor hash value in the request, and recording the token generation event to the distributed ledger; updating the access permission state on the blockchain, and distributing the temporary access token to the requesting doctor through the event push mechanism.

[0012] Further, the validity of the access permission of the requesting party and the temporary access token is verified, and the specific process of generating a hierarchical decryption key according to the data feature descriptor obtained from the blockchain to retrieve the corresponding ciphertext data in the distributed storage system is as follows: receiving the access credential and temporary access token submitted by the requesting party, verifying the validity period and digital signature authenticity of the token through the blockchain intelligent contract, querying the token state information recorded on the blockchain, and confirming that the token has not been used and matches the data feature descriptor hash value of the requested access; verifying whether the medical role attribute contained in the digital identity certificate of the requesting party meets the access permission level required by the data hierarchical identifier; generating a hierarchical decryption key structure based on the temporary access token and the attribute information of the requesting party through a multi-layer key derivation function, which contains a basic key for decrypting metadata and a content key for decrypting specific medical data; locating the corresponding ciphertext data block in the distributed storage system according to the content identifier in the data feature descriptor, obtaining the encrypted data packet from the distributed storage node through a secure transmission protocol, and verifying the integrity signature of the data packet.

[0013] Further, the specific process of re-computing the feature value hash of the decrypted data and comparing it with the original feature value hash stored on the blockchain for verification after decryption by hierarchical decryption key is as follows: the metadata part of the data packet is decrypted by the basic key in the hierarchical decryption key to obtain the data encryption parameters and structure information; the corresponding decryption algorithm is selected according to the encryption scheme identifier in the metadata, the specific medical data content is decrypted by the content key, the original medical data after decryption is re-extracted, the verification feature value hash is generated according to the same window processing and feature value calculation rules as when the evidence is stored; the newly generated feature value hash is compared with the original feature value hash stored on the blockchain bit by bit to verify the data integrity and consistency; after verification, the decrypted medical data is shared with the authorized party through the secure data channel, while the use time and range of the data are limited.

[0014] The present application has the following advantages:

[0015] (1) The obstetrics and gynecology emergency medical data security sharing system based on the blockchain can effectively reduce the exposure risk of patient privacy through the data hierarchical desensitization module for sensitivity grading and differential processing of emergency medical data, and can realize flexible identification and management of different sensitivity data while ensuring data integrity; the chain storage module can analyze the continuous monitoring data stream and extract key physiological features, and realize tamper-proof storage combined with hash operation, ensuring the authenticity and anti-fake of emergency data in the sharing and tracing process, thereby laying a reliable foundation for subsequent safe calling.

[0016] (2) The obstetrics and gynecology emergency medical data security sharing system based on the blockchain can generate temporary tokens through the smart contract mechanism of the emergency access token management module when the emergency doctor makes an emergency request, realize flexible dynamic authorization, and effectively shorten the authorization link response time; at the same time, the secure decryption and data sharing module can generate hierarchical decryption keys according to access permissions and perform layer-by-layer verification to avoid unnecessary full decryption operation, improve decryption efficiency, and realize data consistency verification through hash comparison to ensure the safety and reliability of shared data in emergency scenarios.

[0017] Of course, implementing any product of the present application does not necessarily require all the advantages described above. BRIEF DESCRIPTION OF DRAWINGS

[0018] Figure 1 The flowchart of the obstetrics and gynecology emergency medical data security sharing system based on the blockchain of the present application. DETAILED DESCRIPTION

[0019] The application embodiment solves the problems of insufficient privacy protection, low calling efficiency and inflexible authorization mechanism in the process of safe sharing of medical data among multiple institutions in the gynecological emergency scene.

[0020] The scheme in the application embodiment has the following general idea: the differential protection of sensitive information is realized by setting a data hierarchical desensitization module, the integrity and traceability of emergency monitoring data are guaranteed by an on-chain evidence storage module, a dynamic authorization mechanism is realized in combination with an emergency access token management module, and finally the hierarchical decryption and consistency verification of data are ensured by a secure decryption and data sharing module, so as to guarantee privacy security while meeting the needs of fast data sharing and high reliability in the emergency environment.

[0021] Please refer to Figure 1 The application embodiment provides a technical scheme: a gynecological emergency medical data safe sharing system based on a blockchain, which comprises the following modules: a data hierarchical desensitization module, which is used to establish multi-level desensitization rules according to the sensitivity difference of gynecological emergency data, to perform desensitization and replacement processing on patient personal identifiers according to the multi-level sensitivity rules, and to perform hierarchical identification on medical data itself, and to output gynecological emergency medical data subjected to hierarchical desensitization; an on-chain evidence storage module, which is used to receive desensitized emergency data with hierarchical identification, to perform window processing on continuously generated monitoring data streams, to extract key physiological feature values in each time window and calculate their feature value hashes, to combine the feature value hashes with the data hierarchical identification to generate data feature descriptors, and to submit the hash value of the descriptor as an evidence storage transaction to a blockchain network; an emergency access token management module, which is used to receive emergency access requests of emergency doctors through a smart contract deployed on the blockchain, to initiate a notification to a patient's preset proxy decision maker and to start a timer, and to generate a temporary access token associated with the data feature descriptor hash value after obtaining the proxy voting consent in accordance with the preset rules; and a secure decryption and data sharing module, which is used to verify the access authority of the requester and the validity of the temporary access token and to generate hierarchical decryption keys, to retrieve corresponding ciphertext data in a distributed storage system according to the data feature descriptors obtained from the blockchain, to perform decryption operations through the hierarchical decryption keys, to recalculate the feature value hashes of the decrypted data and to compare them with the original feature value hashes stored on the blockchain, and to share the data with the authorized party and to record the operation log after verification.

[0022] In this embodiment, the data hierarchical desensitization module is responsible for differentiating the protection of different types of emergency medical data in gynecology and obstetrics. Since emergency data contains both direct patient identification information (such as name, ID number, etc.) and sensitive medical parameters (such as fetal heart rate, uterine contraction), it is necessary to establish multi-level desensitization rules according to the sensitivity differences of the data. "Desensitization" refers to processing the original data through encryption, disguise, and intervalization to reduce the risk of privacy leakage. This module will replace highly sensitive personal identifiers with irreversible methods (such as generating pseudo-identifiers through hash calculation), while for partially sensitive data that still requires clinical analysis, it will use numerical range or format retention encryption methods to ensure that the data remains clinically usable while protecting privacy. Finally, the module outputs desensitized data with hierarchical identifiers for subsequent tracking and calling. The on-chain evidence module is responsible for ensuring the integrity and tamper resistance of emergency data. "On-chain evidence" refers to writing the hash of the data's key information (not the data itself) into the blockchain ledger for subsequent verification. Specifically, this module processes the continuous data stream in windows, i.e., it divides the data into segments according to a certain time interval. Key physiological feature values are extracted within each time window, such as fetal heart rate variability features, uterine contraction pressure curve morphology, and maternal circulation indicators. These feature values are then calculated into unique "feature value hashes" using a hash algorithm. To facilitate subsequent retrieval and tracking, the module combines the feature value hashes with the data hierarchical identifiers to generate "data feature descriptors." A "descriptor" is a structured information set used to describe the characteristics of a data packet. Finally, the hash value of the descriptor is submitted to the blockchain to ensure that any subsequent data call can be verified for authenticity through on-chain comparison. The emergency access token management module is responsible for dynamic authorization in emergency scenarios. A "token" is a temporary access credential generated by a smart contract in a blockchain environment, used to prove that a requestor has access rights within a specific time range. In practical applications, emergency doctors can initiate an emergency access request through a smart contract, and the system will automatically send a notification to the patient's pre-set proxy decision maker and start a timer. Only when the proxy agrees according to the rules, will the system generate a temporary access token corresponding to the data feature descriptor. This mechanism ensures data availability in emergencies while preventing unauthorized access. The secure decryption and data sharing module is responsible for hierarchical decryption and consistency verification to ensure that shared data is both secure and reliable. In the specific process, the requestor needs to submit a temporary access token, and the system will verify its legality and assign different levels of decryption keys according to the sensitivity of the data. "Hierarchical decryption" refers to the use of different decryption methods to restore different sensitivity levels of data to prevent low-privileged users from accessing highly sensitive data.Subsequently, the system will retrieve the corresponding ciphertext data in the distributed storage system according to the data feature descriptor on the blockchain, and perform decryption. After decryption, the system will recalculate the feature value hash of the data and compare it with the hash stored on the blockchain to verify that the data has not been tampered with during storage and transmission. Only in the case of successful verification, the system will share the data with the authorized party and automatically record the operation log for traceability.

[0023] Specifically, the establishment logic of the multi-level desensitization rule according to the sensitivity difference of the obstetrics and gynecology emergency data is as follows: different data types in the obstetrics and gynecology emergency data are identified, and the data is divided into four categories: personal identifier, quasi identifier, sensitive medical data and general medical data; according to the order of data sensitivity from high to low, the personal identifier is defined as the first sensitivity level, the quasi identifier is defined as the second sensitivity level, the sensitive medical data is defined as the third sensitivity level, and the general medical data is defined as the fourth sensitivity level; each sensitivity level is configured with corresponding desensitization processing strength, wherein the first sensitivity level is configured with irreversible replacement processing of hash algorithm, the second sensitivity level is configured with format reservation encryption processing, the third sensitivity level is configured with numerical intervalization processing based on a preset threshold range, and the fourth sensitivity level is configured with minimal processing based on key field removal; the mapping relationship between the sensitivity level and the desensitization processing strength is established, and a multi-level desensitization rule system is formed.

[0024] In this embodiment, first, the emergency data is classified to identify different data types, including: personal identifiers such as name, ID number, contact information, etc., which can directly point to the patient's identity; quasi-identifiers such as hospital number, date of birth, address, etc., which alone may not be able to determine the patient's identity but can infer the identity when combined with other information; sensitive medical data such as fetal heart rate curve, contraction intensity, previous delivery history, etc., which involves the health status of mother and baby; general medical data such as examination time, department category, routine test values, etc., which has lower privacy sensitivity. Second, according to the data sensitivity from high to low, four sensitivity levels are set: the first sensitivity level (highest): personal identifiers; the second sensitivity level: quasi-identifiers; the third sensitivity level: sensitive medical data; the fourth sensitivity level (lowest): general medical data. Then, configure the corresponding desensitization processing methods for different sensitivity levels: the first level uses irreversible replacement processing of hash algorithm. Hash is a one-way function that can convert identity information into a fixed-length pseudo-identifier, which cannot be inferred from the result to the original identity, thus maximizing the protection of patient identity. The second level uses format-preserved encryption processing. This encryption method preserves the original format of the data, such as dates still displayed as date format, but the specific values are encrypted and replaced, which protects privacy and preserves system compatibility. The third level uses threshold-based numerical intervalization processing. For example, specific fetal heart rate values are converted to "normal range", "high", "low" intervals, etc., without directly exposing the exact value, thus reducing the risk of sensitive information leakage while preserving the value of clinical judgment. The fourth level uses minimal processing of key field removal. For example, delete the minutes and seconds in the timestamp, only keep the date, remove unnecessary fine-grained information, and reduce redundant privacy exposure. Finally, establish the mapping relationship between the sensitivity level and the desensitization processing intensity through the above rules to form a complete multi-level desensitization system. In this way, different sensitivity data will adopt differentiated protection strategies when sharing, which can meet the clinical use needs of emergency doctors and maximize the protection of patient privacy and security.

[0025] Specifically, according to the multi-level sensitivity rule, the patient personal identifier is desensitized and replaced, and the medical data itself is hierarchically identified, and the specific process of outputting the hierarchical desensitized gynecological emergency medical data is as follows: the personal identifier of the first sensitivity level is hashed to generate a pseudonymized identifier, the quasi-identifier of the second sensitivity level is processed by the AES encryption algorithm, the original data format features are maintained, the sensitive medical data of the third sensitivity level is converted by numerical range, and the general medical data of the fourth sensitivity level is removed by identifier processing; add sensitivity level label to each processed gynecological emergency data element, repackage the processed data element according to the emergency event time axis, add metadata containing generation timestamp and processing agency information in the data packet, sign and verify the complete data packet by asymmetric key digital signature algorithm, and output the hierarchical desensitized gynecological emergency medical data. In the embodiment, the personal identifier desensitization processing will irreversibly replace the personal identifier belonging to the first sensitive level. Specifically: the identifier is hashed to obtain a pseudonymized identifier ; wherein: the original personal identifier; the preset SHA-256 hash function has one-way and collision resistance; the generated pseudonymized identifier. This processing ensures that the original identifier cannot be recovered by calculation. The quasi-identifier encryption processing will process the quasi-identifier data of the second sensitive level by format-preserving encryption to obtain the encryption result ; wherein: : the original quasi-identifier; the symmetric encryption function based on the AES algorithm; the dynamically generated symmetric encryption key is determined by the random number generator and the seed parameter; the encrypted quasi-identifier. The key is generated in the following manner: ; wherein: : system random number; security seed; : key derivation function. The sensitive medical data interval processing will convert the sensitive medical numerical data belonging to the third sensitive level to a range value ; wherein; the original sensitive medical data; : a set of preset thresholds for defining interval boundaries; interval function, which maps the original numerical value to the corresponding interval label; the intervalized numerical label. The determination method of the threshold set is based on historical sample distribution, using quantile method: ; wherein: : a historical sample set of similar sensitive medical data; : quantile function, according to the proportion b cutting the data distribution; : the resulting threshold set. General medical data minimization processing of general medical data for the fourth sensitivity level key field removal, only retaining necessary context information, resulting in minimized data . This processing does not involve calculation, and directly removes the specified field in structured data. The hierarchical label is encapsulated with the data as all processed data elements adding the corresponding sensitivity level label, re-encapsulating according to the emergency event timeline to form a data package . Meta data addition and signature verification adds meta data in the data package , including generating a timestamp and processing agency information; then signing the complete data package using a signature algorithm of an asymmetric key: ; wherein: : hierarchical desensitized medical data package; meta data; : splicing operation; : signature private key; : generated digital signature. The receiving end verifies by the corresponding public key : When the verification is successful, the data package can be safely used for emergency decision-making.

[0026] Specifically, the desensitized emergency data with hierarchical identification is received, and the continuous monitoring data stream is processed in windows, the key physiological feature values in each time window are extracted, and the specific process of calculating the feature value hash is as follows: according to the clinical characteristics of the obstetric emergency monitoring data, the adaptive time window length is set, the continuous vital sign data stream is processed by equal-length segmentation, the key physiological parameters reflecting the safety state of mother and infant are extracted in each time window, including fetal heart rate variation characteristics, uterine contraction pressure curve morphology, and maternal circulation function indicators; the original sampling data is filtered by a weighted moving average algorithm to suppress measurement noise interference, and the statistical characteristic quantity of the feature parameters in each time window is calculated, including the trend change rate, the abnormal fluctuation amplitude, and the stable interval range; the statistical characteristic quantity and the time window label information are paired and combined to construct a multi-dimensional feature vector, and after normalization, an irreversible feature value hash is generated by a hash algorithm.

[0027] In this embodiment, the time window segmentation is set according to the clinical characteristics of the obstetric emergency monitoring data The continuously generated vital sign data stream Perform equal-duration segmentation processing. The length of the time window is adaptively determined by the characteristics of fetal heart rate and uterine contraction fluctuations; for example, it can be dynamically adjusted based on the variance of data over the past minute. Continuous vital signs data stream, including fetal heart rate, uterine contraction pressure, maternal circulatory indicators, etc. Key physiological parameters are extracted within each time window, reflecting the safety status of both mother and baby: fetal heart rate variability characteristics. This indicates the fluctuation of fetal heart rate over time, including mean heart rate (STV) and long-term variability (LTV). ;in, For the mth element within the window Fetal heart rate at each sampling point This represents the average fetal heart rate within the window. This represents the number of sampling points within the window; used to quantify fetal heart rate stability. Contraction pressure curve morphology (UCk): represents the intensity and frequency characteristics of the contraction waveform, including peak amplitude, duration, and interval; the area and waveform changes of the contraction curve within each window can be calculated through weighted integration. ;in, For the first The uterine contraction pressure value at each sampling point The weighting coefficients can be determined based on time decay or peak importance. Maternal circulatory function indicators (MCk): including blood pressure, heart rate, and blood oxygen saturation, used to assess maternal circulatory status; statistic calculation formula: ;in This represents the average blood pressure. This represents the average maternal heart rate. This represents the average blood oxygen saturation level. Weighted moving average filtering applies a weighted moving average to the original sampled data to suppress noise interference. ;in These are the original sampled values. The filtered value. The weighting coefficients can be set in descending order from the center point to ensure that the data in the middle of the window has the highest weight. The sliding window is half its width. Statistical characteristic calculations are performed on key parameters within each window, including the rate of change of trend, the magnitude of abnormal fluctuations, and the range of stable intervals: Rate of change of trend. ;in and These are the end and beginning sample values ​​of the window, respectively. Abnormal fluctuation amplitude. The window exceeds the set threshold. Numerical difference: ;where the threshold Determined according to clinical standards. Stable interval range : The longest duration that the continuous sampling points fall within the safety range, indicating the stability of the physiological parameters. Multi-dimensional feature vector construction and normalization combine the above statistical features with time window marking information: ; Normalization processing (such as Min-Max or Z-score) is performed on to generate a standardized multi-dimensional feature vector . Feature value hash generation generates an irreversible feature value hash for the normalized feature vector through a hash algorithm: ; Where Hash() can use the SHA-256 irreversible hash algorithm to ensure that each time window corresponds to a unique and tamper-proof feature value hash. In actual obstetric emergency scenarios, when a pregnant woman experiences abnormal uterine contractions or fetal heart rate fluctuations, the system receives continuous vital sign data streams that have undergone hierarchical desensitization processing and automatically segments the data according to adaptive time windows. Within each time window, the system can accurately extract key physiological parameters such as fetal heart rate variability features, uterine contraction pressure curve morphology, and maternal circulatory function indicators, while calculating statistical feature quantities based on trend changes, abnormal fluctuations, and stability information. Through multi-dimensional feature vector construction and normalization processing, the system generates a unique feature value hash, achieving irreversible identification and integrity protection of continuous monitoring data.

[0028] Specifically, the feature value hash and data hierarchical identifier are combined to generate a data feature descriptor, and the hash value of the descriptor is submitted to the blockchain network as a notarization transaction. The specific process is as follows: a mapping relationship table of feature value hash and corresponding data hierarchical identifier is established, and a timestamp sequence and data type classification information are added; the combined information is structured and packaged in TLV format, where the type field identifies the data type, the length field records the data size, and the value field stores the specific content; version control information and integrity check code are added to the descriptor to generate a standardized data feature descriptor. After the descriptor is serialized and encoded, a unique content identifier is generated through hash operation; the content identifier is bound with the storage path information of the original data to construct a complete notarization transaction message, and the notarization request is submitted through the transaction interface of the blockchain node. The key information of the feature descriptor is written into the distributed ledger.

[0029] In this embodiment, a mapping relationship table is established to construct a mapping relationship table of feature value hash and data hierarchical identifier. For each data sample, let its feature value hash be , and the hierarchical identifier be , then the mapping function is defined as: ; Wherein, : Feature value hash calculated from original data; : Hierarchical identifier corresponding to the data; This is a unique entry in the mapping table. This step ensures that each piece of data can be quickly located to its security level using its hash value. The timestamp and type information are combined in the mapping result. Add timestamp sequences and data type classification information to form a combined vector: ;in, : Timestamp of data generation or processing; Data type classification information (such as images, documents, sensor streams). TLV format encapsulation combines information. Encapsulated according to TLV structure: Type: Corresponding ;Length: Size of the record value field Value: Stores the combined content. This step is purely formatting and does not involve calculations. Add version and verification information: Add a version control number to the TLV encapsulation result. and integrity check code The check digit can be calculated using the following formula: ;in, Version number; : Encapsulated content; One-way hash function; Bitwise XOR operation. This ensures traceability between different versions of the descriptor, and the verification result can quickly verify integrity. Generating standardized descriptors integrates the above content into standardized data feature descriptors. Serialization and hash calculation pair Serialization encoding is performed to obtain a binary stream. Then calculate the unique content identifier: ;in, : Serialization result; Unique content identifier. The content identifier is bound to storage path information. Compared with the original data storage path Binding is performed to generate a certificate storage message: ;in, : The storage path of the raw data (such as the address of a distributed file system); : Notarization transaction message. Submitted to the blockchain network, the notarization request is submitted through the blockchain node transaction interface, including the core fields in the message. and Write to a distributed ledger to achieve immutable evidence storage. Verification code. The generation method adopts a combination strategy based on hash and XOR operation, which can ensure that even different versions of the same data can be distinguished. In the emergency scene of gynecology and obstetrics, the system will combine the hash of the feature value extracted from the continuously monitored desensitized vital sign data and the classified sensitive medical data with the corresponding classification identifier to generate a standardized data feature descriptor. By adding a timestamp, data type information, and a version number and integrity check code, the system ensures that each descriptor can uniquely identify the corresponding data and trace its generation and processing process. The unique content identifier generated after serialization encoding is bound to the original data storage path and submitted to the blockchain node for evidence transaction, realizing tamper-proof protection of data integrity and security. This processing step can quickly verify the authenticity and integrity of the data in the emergency environment, providing a reliable basis for subsequent secure sharing and authorized access, while ensuring that even if there are multiple versions of the data, they can be accurately distinguished and tracked through the check code, improving the credibility and operational efficiency of medical data management.

[0030] Specifically, the emergency access token management module includes the following steps: receiving an emergency access request submitted by an emergency doctor through an intelligent contract interface deployed on the blockchain, which includes the doctor's identity certificate, the patient's medical record identifier, and the data feature descriptor hash value of the requested access; after verifying the legality of the doctor's identity, sending an access authorization request notification to at least two proxy decision makers preset by the patient, and starting a configurable timer to set a voting decision time window; collecting and verifying the digital signature voting response of the proxy decision maker in real time through the voting of the intelligent contract, and when the consent vote that meets the preset multi-signature rule is obtained before the timer expires, generating a time-limited temporary access token, and recording the temporary access token with the data feature descriptor hash value in the request; updating the access permission state on the blockchain, and recording the token generation event to the distributed ledger, and distributing the temporary access token to the requesting doctor through the event push mechanism.

[0031] In this embodiment, the access request is received through an intelligent contract interface deployed on the blockchain to receive an emergency access request submitted by an emergency doctor. The request includes three parts: the doctor's identity certificate, the patient's medical record identifier, and the feature descriptor hash value of the target data The identity verification intelligent contract calls the doctor's public key registered on the chain to verify its identity certificate, and if it matches, it enters the authorization process. Only digital signature verification is involved here. After identity verification, the system sends an access authorization request notification to at least two proxy decision makers preset by the patient, and simultaneously starts a configurable timer. The set time window is , within which the voting collection must be completed. Collect and verify the voting response Proxy decision makers generate digital signature votes through their private keys and submit them to the intelligent contract. Let the voting set collected by the system be: ; wherein, : the th bit of the voting result of the proxy decision maker, taking value 1 for agreement and 0 for rejection; : the number of proxies who validly submit votes within the time window . The smart contract needs to determine whether the set meets the multisignature rule. Let the rule threshold be , then the determination condition is: ; wherein, : the th weight coefficient of the proxy decision maker; : the voting value (1 for agreement and 0 for rejection); : the weighted voting score; : the voting threshold. The determination method of the weight coefficient : According to the authorization level defined by the patient in the initial setting, for example, the voting weight of direct relatives is 1.0, the voting weight of the attending physician is 0.8, and the voting weight of the rest of the proxies is 0.5. The determination method of the threshold : It can be defined as a fixed proportion of the total weight sum, for example, set the threshold to 60% of the total weight sum, that is: , ; wherein is the proportion factor, which is specified by the patient in the preset strategy. When the determination condition is met within the time window , the system generates a temporary access token with time effectiveness. Its generation method can be represented as: ; wherein, : the data feature descriptor hash value submitted in the request; : a random number generated by the smart contract, used to prevent token replay; : token expiration timestamp; : a secure hash function; : represents the concatenation operation. The generated token is bound to the data feature descriptor hash value , and the access permission state on the blockchain is updated. At the same time, the token generation event is recorded in the distributed ledger to ensure full traceability. The temporary access token is securely distributed to the requesting doctor through the on-chain event push mechanism. The doctor can use the token to access the patient's specified data within the expiration time .

[0032] In particular, the specific process of verifying the access right of the requestor and the validity of the temporary access token and generating the hierarchical decryption key according to the data feature descriptor obtained from the blockchain is as follows: receiving the access credential and the temporary access token submitted by the requestor, verifying the validity period and the authenticity of the digital signature of the token through the blockchain smart contract, querying the token state information recorded on the blockchain, confirming that the token has not been used and matches the data feature descriptor hash value of the requested access; verifying whether the medical role attribute contained in the digital identity certificate of the requestor meets the access right level required by the data hierarchical identifier, generating a hierarchical decryption key structure based on the temporary access token and the attribute information of the requestor through a multi-layer key derivation function, which includes a basic key for decrypting metadata and a content key for decrypting specific medical data; locating the corresponding ciphertext data block in the distributed storage system according to the content identifier in the data feature descriptor, obtaining the encrypted data packet from the distributed storage node through a secure transmission protocol, and verifying the integrity signature of the data packet.

[0033] In the present embodiment, the system for receiving and verifying access credentials first receives the access credential and the temporary access token submitted by the requestor . The blockchain smart contract is called to verify whether the validity period of the token is within the expiration timestamp; the authenticity of the digital signature of the token is checked; the token state recorded in the blockchain ledger is queried to ensure that the token has not been used and matches the hash value of the target data feature descriptor . This step ensures that the access credential is legal and has not been tampered with. The medical role attribute contained in the digital identity certificate of the requestor is verified to determine whether it meets the access right level requirement corresponding to the data hierarchical identifier . The decision rule formula can be expressed as: ; wherein, : the permission decision result, taking the value 1 to indicate pass and 0 to indicate rejection; : the role attribute set of the requestor; : the access level corresponding to the data hierarchical identifier; , the key generation step is entered; otherwise, the request is rejected. The hierarchical decryption key is generated, and the system executes a multi-layer key derivation function based on the temporary access token and the attribute information of the requestor to generate a hierarchical decryption key structure. The formula is: ; wherein, : the derived layer decryption key; : the temporary access token; : the role attribute of the requestor; : a system random factor for ensuring the uniqueness of the key in different sessions; : Multi-layered key derivation function : Connection operator. The hierarchical key structure contains: base key : Used to decrypt metadata (timestamp, signature, etc. basic information); content key : Used to decrypt specific medical data content; other layers can be extended to support fine-grained access control. Content identifier locates and retrieves ciphertext data blocks according to the content identifier in the data feature descriptor , in the distributed storage system. Find the storage node location through the distributed index table; start the secure transmission protocol (such as TLS or link encryption protocol) to request the ciphertext data packet. After obtaining the encrypted data packet, the integrity signature is verified. Let the received data packet be , the signature is , and the verification function is: ; wherein, : Verification result, value 1 means pass, 0 means fail; : Received ciphertext data packet; : Data integrity signature; : Public key of the storage node; Signature verification function. Only when , the system allows subsequent decryption operations.

[0034] Specifically, through the hierarchical decryption key, the decrypted data is re-computed and compared with the original feature value hash stored on the blockchain. The specific process of sharing data to the authorized party and recording operation log after verification is as follows: decrypt the metadata part of the data packet through the base key in the hierarchical decryption key, obtain the data encryption parameter and structure information; according to the encryption scheme identifier in the metadata, select the corresponding decryption algorithm, decrypt the specific medical data content through the content key, re-extract the features of the decrypted original medical data, and generate the verification feature value hash according to the same window processing and feature value calculation rules as when storing the evidence; compare the newly generated feature value hash with the original feature value hash stored on the blockchain bit by bit to verify the data integrity and consistency; after verification, share the decrypted medical data to the authorized party through the secure data channel, while limiting the use duration and range of the data.

[0035] In this embodiment, the decryption metadata system first decrypts the metadata part of the data packet using the base key in the hierarchical decryption key , obtains the encryption parameter . This step ensures the correct decryption algorithm and parsing rules are selected. The decrypted medical data content is identified by the encryption scheme in the metadata, and the system selects the corresponding decryption algorithm. The content key in the hierarchical decryption key is used to decrypt the medical data content The medical data subject is decrypted to obtain the original medical data stream , and the feature parameters are extracted according to the same windowing processing and feature value calculation rules as when the evidence is stored, forming a feature vector . The feature parameter calculation can be expressed as: ; where: : trend change rate; : abnormal fluctuation amplitude; : stable interval range and other statistical characteristics. After obtaining the feature vector, the system performs the normalization function to generate a standardized vector , and then calculates the verification feature value hash using the hash function : ; where: : newly generated feature value hash; : normalized feature vector; : windowed timestamp sequence; : structure information in the metadata; : hash function for generating fixed-length digest; : represents the concatenation operation. The blockchain hash comparison compares the generated feature value hash with the original feature value hash stored on the blockchain. The comparison formula is: ; where: : difference count value; : total length of hash value bits; : the bit of the newly generated hash; : the bit of the blockchain stored hash; : bit comparison function, if then take 0, otherwise take 1. When , it is determined that the data integrity and consistency verification is passed. After the verification is passed, the system sends the decrypted medical data to the authorized party through a secure data channel. At the same time, based on the pre-set policy control parameters , the data usage duration and range are limited. The control policy can be expressed as: ; where: : data sharing control result; : decrypted medical data; : A set of usage restriction parameters, including maximum usage duration and usage scope; : A policy enforcement function to trim, mask, or time-destroy data. The decryption process explains how to use the base key and content key hierarchical decryption. The comparison formula uses bit-by-bit difference count to indicate that only when can pass the verification. Data sharing and restriction are disclosed by controlling function to limit the duration and scope, avoiding data overuse.

[0036] In summary, the present application has at least the following effects:

[0037] The obstetrics and gynecology emergency medical data security sharing system based on blockchain realizes fine management and rapid retrieval of sensitive information through hierarchical desensitization and feature value hash evidence, enabling emergency doctors to quickly obtain the required data in emergency situations, significantly improving the timeliness of emergency decision-making. The multi-level desensitization rules, hierarchical encryption, and temporary access token mechanism, combined with the tamper-proof nature of blockchain, ensure the security and traceability of patient personal information and medical data during sharing and storage. Through smart contracts and multi-signature proxy decision mechanisms, dynamic authorization and real-time supervision of emergency access are realized, ensuring that data sharing meets emergency needs while limiting access permissions and usage scope. Through hierarchical decryption, feature value hash comparison, and secure data channel transmission, the integrity of shared data is verified to ensure that the data obtained by authorized parties is consistent with the stored data, reliable and usable. The system design takes into account multi-agency data collaboration, supporting distributed storage and blockchain network expansion, enabling obstetrics and gynecology emergency data to be safely and efficiently shared and called between different medical institutions.

[0038] Those skilled in the art will appreciate that embodiments of the application can be provided as methods, systems or computer program products. Accordingly, the application can be embodied in the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the application can be embodied in the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk memory, CD-ROMs, optical memory, etc.) having computer usable program code embodied therein.

[0039] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0040] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the function specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0041] The computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 one or more flowcharts and / or blocks Figure 1 means for functionally implementing the steps listed in the flowchart block or blocks.

[0042] While the preferred embodiments of the application have been described, additional variations and modifications can be employed by those skilled in the art. Therefore, the appended claims intend to cover all such modifications and variations as fall within the true spirit and scope of the present application. Further, the appended claims can be construed to cover all alternatives falling within the equivalent range of the claims.

[0043] It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application cover the modifications and variations of this application provided they come within the scope of the appended claims and their equivalents.

Claims

1. A blockchain-based obstetric and gynecological emergency medical data secure sharing system, characterized in that, Includes the following modules: The data grading and desensitization module is used to establish multi-level desensitization rules based on the sensitivity differences of obstetric and gynecological emergency data. According to the multi-level sensitivity rules, the patient's personal identifier is desensitized and replaced. At the same time, the medical data itself is graded and labeled, and the graded and desensitized obstetric and gynecological emergency medical data is output. The on-chain evidence storage module is used to receive desensitized emergency data with graded identifiers, perform windowing processing on the continuously generated monitoring data stream, extract key physiological feature values ​​within each time window and calculate their feature value hash, combine the feature value hash with the data graded identifier to generate a data feature descriptor, and submit the hash value of the descriptor as an evidence storage transaction to the blockchain network. The emergency access token management module is used to receive emergency access requests from emergency physicians through smart contracts deployed on the blockchain, send notifications to the patient's pre-set agent decision-makers and start a timer, and generate a temporary access token associated with the hash value of the data feature descriptor after obtaining the agent's vote of consent in accordance with the pre-set rules. The security decryption and data sharing module is used to verify the requester's access permissions and the validity of the temporary access token and generate a hierarchical decryption key. Based on the data feature descriptor obtained from the blockchain, it retrieves the corresponding encrypted data in the distributed storage system, performs decryption operation through the hierarchical decryption key, recalculates the feature value hash of the decrypted data and compares it with the original feature value hash stored on the blockchain for verification. After successful verification, it shares the data with the authorized party and records the operation log. The specific process of receiving desensitized emergency rescue data with graded identifiers, performing windowing processing on the continuously generated monitoring data stream, extracting key physiological feature values ​​within each time window, and calculating their feature value hashes is as follows: Based on the clinical characteristics of obstetric and gynecological emergency monitoring data, an adaptive time window length is set, and the continuously generated vital sign data stream is processed in segments of equal duration. Within each time window, key physiological parameters reflecting the safety status of the mother and baby are extracted, including fetal heart rate variability characteristics, uterine contraction pressure curve morphology, and maternal circulatory function indicators. The original sampled data is filtered by a weighted moving average algorithm to suppress measurement noise interference. Statistical characteristics of the feature parameters within each time window are calculated, including the trend change rate, abnormal fluctuation amplitude, and stable interval range. Statistical features are paired and combined with time window marker information to construct a multidimensional feature vector. After normalization, an irreversible feature value hash is generated using a hash algorithm. The specific process of combining the feature value hash with the data hierarchy identifier to generate a data feature descriptor, and then submitting the hash value of this descriptor to the blockchain network as a notarized transaction, is as follows: Establish a mapping table between feature value hashes and corresponding data hierarchical identifiers, and add timestamp sequences and data type classification information; The combined information is encapsulated in a structured manner using the TLV format, where the type field identifies the data type, the length field records the data size, and the value field stores the specific content. Version control information and integrity check codes are added to the descriptor to generate a standardized data feature descriptor. After serialization encoding of the descriptor, a unique content identifier is generated through hash operation. By binding the content identifier with the storage path information of the original data, a complete evidence storage transaction message is constructed. The evidence storage request is submitted through the transaction interface of the blockchain node, and the key information of the feature descriptor is written into the distributed ledger.

2. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 1, characterized in that: The logic behind establishing multi-level desensitization rules based on the sensitivity differences in obstetric and gynecological emergency data is as follows: Identify different data types in obstetric and gynecological emergency data and classify the data into four categories: personal identifiers, quasi-identifiers, sensitive medical data, and general medical data. Based on the order of data sensitivity from high to low, personal identifiers are defined as the first sensitivity level, quasi-identifiers as the second sensitivity level, sensitive medical data as the third sensitivity level, and general medical data as the fourth sensitivity level. Each sensitivity level is configured with a corresponding desensitization processing strength. The first sensitivity level is configured with irreversible replacement of hash algorithm, the second sensitivity level is configured with format preservation encryption, the third sensitivity level is configured with numerical interval processing based on a preset threshold range, and the fourth sensitivity level is configured with minimization processing based on key field removal. A mapping relationship between sensitivity level and desensitization processing strength is established to form a multi-level desensitization rule system.

3. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 2, characterized in that: The specific process of desensitizing and replacing patient personal identifiers according to multi-level sensitivity rules, while simultaneously classifying and labeling the medical data itself, and outputting graded desensitized obstetric and gynecological emergency medical data is as follows: The system performs hash calculations on personal identifiers at the first sensitivity level to generate pseudonymous identifiers, processes quasi-identifiers at the second sensitivity level using the AES encryption algorithm to maintain their original data format characteristics, performs numerical range conversion on sensitive medical data at the third sensitivity level, and removes identifiers from general medical data at the fourth sensitivity level. Sensitivity level labels are added to each processed obstetric and gynecological emergency data element. The processed data elements are repackaged according to the emergency event timeline. Metadata containing generation timestamps and processing agency information is added to the data packet. The complete data packet is signed and verified using an asymmetric key digital signature algorithm. The resulting graded and desensitized obstetric and gynecological emergency medical data is output.

4. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 1, characterized in that: The emergency access token management module includes the following steps: The system receives emergency access requests submitted by emergency physicians through a smart contract interface deployed on the blockchain. These requests include physician identity credentials, patient medical record identifiers, and hash values ​​of the data feature descriptors requested for access. After verifying the doctor's identity, an access authorization request notification is sent to at least two pre-selected proxy decision-makers of the patient, and a timer with configurable duration is started to set the voting decision time window; The smart contract collects and verifies the digital signature voting response of the proxy decision-maker in real time. When a vote of agreement that meets the preset multi-signature rules is obtained before the timer expires, a temporary access token with a time limit is generated and the temporary access token is bound and recorded with the hash value of the data feature descriptor in the request. Update the access permission status on the blockchain and record the token generation event to the distributed ledger. Securely distribute the temporary access token to the requesting doctor through the event push mechanism.

5. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 4, characterized in that: The specific process of verifying the requester's access permissions and the validity of the temporary access token, generating a hierarchical decryption key, and retrieving the corresponding encrypted data in the distributed storage system based on the data feature descriptor obtained from the blockchain is as follows: Receive the access credentials and temporary access token submitted by the requester, verify the validity period and digital signature authenticity of the token through a blockchain smart contract, query the token status information recorded on the blockchain, and confirm that the token has not been used and matches the hash value of the data feature descriptor requested for access. Verify whether the medical role attributes contained in the requester's digital identity certificate meet the access permission level requirements of the data classification identifier. Generate a hierarchical decryption key structure based on the temporary access token and the requester's attribute information through a multi-level key derivation function. This structure contains a base key for decrypting metadata and a content key for decrypting specific medical data. The corresponding encrypted data block in the distributed storage system is located based on the content identifier in the data feature descriptor. The encrypted data packet is obtained from the distributed storage node through a secure transmission protocol, and the integrity signature of the data packet is verified.

6. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 5, characterized in that: The process of decryption using a layered decryption key, recalculating the feature hash of the decrypted data and comparing it with the original feature hash stored on the blockchain, sharing the data with the authorized party and recording the operation log after successful verification is as follows: The metadata portion of the data packet is decrypted using the base key in the layered decryption key to obtain the data encryption parameters and structure information; Select the corresponding decryption algorithm based on the encryption scheme identifier in the metadata, decrypt the specific medical data content using the content key, re-extract features from the decrypted original medical data, and generate a verification feature hash according to the same windowing processing and feature value calculation rules as when storing evidence. The newly generated feature value hash is compared bit by bit with the original feature value hash stored on the blockchain to verify data integrity and consistency; After successful verification, the decrypted medical data is shared with the authorized party through a secure data channel, while the duration and scope of data usage are restricted.

Images