Block chain-based gynaecology and obstetrics emergency medical data security sharing system

Abstract

The invention discloses a gynaecology and obstetrics emergency medical data security sharing system based on a block chain, and relates to the technical field of medical information processing. The method is used for solving the security and timeliness problems of multi-mechanism data sharing in an emergency scene. The method comprises the following steps: firstly, performing grading processing and desensitization on personal identifiers and medical data of patients through a data grading and desensitization module, and outputting data which can be safely shared; then, an on-chain evidence storage module performs windowing processing on the continuous monitoring data flow, extracts key physiological features, generates feature value Hash, constructs data feature descriptors and submits the data feature descriptors to a block chain network; the emergency access token management module realizes dynamic authorization through a smart contract, and generates a temporary access token associated with the data feature descriptor; and finally, the secure decryption and data sharing module verifies the authority based on the hierarchical decryption key, decrypts the data and compares the eigenvalue hash, and shares and records an operation log with an authorization party after ensuring the data integrity, thereby realizing efficient, secure and traceable data sharing.

Description

Technical Field

[0001] This invention relates to the field of medical information processing technology, specifically a blockchain-based system for secure sharing of emergency medical data in obstetrics and gynecology. Background Technology

[0002] With the increasing demand for emergency and critical care in obstetrics and gynecology, a large amount of real-time maternal and infant vital signs data, monitoring records, and emergency treatment information are generated in the clinical environment. How to achieve efficient sharing and rapid access among multiple institutions while ensuring patient privacy and data security has become a crucial issue for improving emergency response efficiency and reducing risks to mothers and infants. Traditional medical data exchange methods mostly rely on centralized platforms or point-to-point transmission, which not only carries the risk of interception and tampering during transmission but also makes it difficult to fully trace the data usage process, failing to meet the dual requirements of timeliness and security in emergency scenarios.

[0003] For example, Chinese invention patent CN119580911B discloses a data security sharing method, system, and device. The method includes: a doctor creating an EMR for a patient; the doctor encrypting the generated EMR using the patient's public key; and storing the encrypted EMR on a cloud server. The blockchain stores information such as the patient's EMR keywords, hash values, and logs. A retrieval service is provided using the keywords, returning the EMR's hash value and index. An inverted index-based blockchain encrypted retrieval method is used to retrieve the encrypted EMR on the cloud server. This method achieves efficient encrypted retrieval, thereby comprehensively improving the shortcomings of existing electronic medical record systems in terms of data sharing, efficiency, and security.

[0004] However, this type of method still has some substantial drawbacks in obstetric and gynecological emergency applications: First, the overall encryption and decryption of medical record data can lead to lengthy data retrieval processes in emergency situations, making it impossible to guarantee that information can be quickly retrieved to support real-time decision-making; second, the encrypted retrieval process mainly relies on keyword indexing, making it difficult to differentiate between different types of medical data. Doctors are often forced to decrypt content unrelated to diagnosis and treatment when retrieving data, thus increasing the possibility of privacy leaks; finally, the access control mechanism is designed as a fixed process, which is slow to respond to sudden emergency requests, and the authorization chain is prone to delays, affecting the immediate availability of emergency data. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a blockchain-based obstetric and gynecological emergency medical data security sharing system, which solves the problems mentioned in the background.

[0006] To achieve the above objectives, this invention provides the following technical solution: a blockchain-based obstetric and gynecological emergency medical data security sharing system, comprising the following modules: a data grading and desensitization module, used to establish multi-level desensitization rules based on the sensitivity differences of obstetric and gynecological emergency data, perform desensitization and replacement processing on patient personal identifiers according to the multi-level sensitivity rules, and simultaneously grade and identify the medical data itself, outputting graded and desensitized obstetric and gynecological emergency medical data; and an on-chain evidence storage module, used to receive desensitized emergency data with grading 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 hashes, combine the feature value hashes with the data grading identifiers to generate a data feature descriptor, and submit the hash value of the descriptor as an evidence storage transaction to the blockchain. The blockchain network includes an emergency access token management module, which receives emergency access requests from paramedics via smart contracts deployed on the blockchain, notifies the patient's pre-defined decision-makers, starts a timer, and generates a temporary access token associated with a data feature descriptor hash value after obtaining proxy votes that meet preset rules. A secure decryption and data sharing module verifies the requester's access rights and the validity of the temporary access token, generates a hierarchical decryption key, retrieves the corresponding encrypted data from the distributed storage system based on the data feature descriptor obtained from the blockchain, performs decryption using the hierarchical decryption key, recalculates the feature value hash of the decrypted data, compares it with the original feature value hash stored on the blockchain, shares the data with the authorized party after successful verification, and records the operation log.

[0007] Furthermore, the logic for establishing multi-level desensitization rules based on the sensitivity differences of obstetric and gynecological emergency data is as follows: Different data types in the obstetric and gynecological emergency data are identified and divided into four categories: personal identifiers, quasi-identifiers, sensitive medical data, and general medical data. According to 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. A corresponding desensitization processing intensity is configured for each sensitivity level: irreversible substitution processing using hash algorithms is configured for the first sensitivity level, format preservation encryption processing is configured for the second sensitivity level, numerical interval processing based on a preset threshold range is configured for the third sensitivity level, and minimization processing based on key field removal is configured for the fourth sensitivity level. A mapping relationship between sensitivity levels and desensitization processing intensity is established, forming a multi-level desensitization rule system.

[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] Furthermore, the emergency access token management module includes the following steps: receiving emergency access requests submitted by emergency physicians through a smart contract interface deployed on the blockchain. These requests include the physician's identity credentials, the patient's medical record identifier, and the hash value of the data feature descriptor requested for access. After verifying the physician's legitimacy, an access authorization request notification is sent to at least two pre-selected decision-makers, while simultaneously starting a configurable timer to set a voting decision time window. The module receives and verifies the digital signature voting responses of the decision-makers in real time through the smart contract's vote collection mechanism. When a vote conforming to the pre-selected multi-signature rules is obtained before the timer expires, a time-limited temporary access token is generated and bound to the hash value of the data feature descriptor in the request. The access permission status on the blockchain is updated, and the token generation event is recorded in the distributed ledger. The temporary access token is then securely distributed to the requesting physician through an event push mechanism.

[0012] Further, the specific process of verifying the requester's access rights 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: The requester submits access credentials and a temporary access token; the validity period and digital signature authenticity of the token are verified through a blockchain smart contract; the token status information recorded on the blockchain is queried to confirm that the token has not been used and matches the hash value of the requested data feature descriptor; the medical role attributes contained in the requester's digital identity certificate are verified to meet the access rights level required by the data classification identifier; a hierarchical decryption key structure is generated based on the temporary access token and the requester's attribute information through a multi-level key derivation function, which includes 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 according to 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.

[0013] Furthermore, the specific process of decryption using a layered decryption key, recalculating the feature hash of the decrypted data, comparing it with the original feature hash stored on the blockchain, and sharing the data with the authorized party after successful verification, while recording the operation log, 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 structural information; the corresponding decryption algorithm is selected based on the encryption scheme identifier in the metadata, and the specific medical data content is decrypted using the content key; the original decrypted medical data undergoes re-feature extraction, and a verification feature hash is generated according to the same windowing processing and feature value calculation rules as during evidence storage; the newly generated feature hash is compared bit-by-bit with the original feature 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 restricting the data's usability duration and scope.

[0014] The present invention has the following beneficial effects: (1) The blockchain-based obstetric and gynecological emergency medical data security sharing system uses a data classification and desensitization module to classify and differentiate emergency medical data based on sensitivity. This can effectively reduce the risk of exposure of patients' personal privacy and achieve flexible identification and management of data with different sensitivities while ensuring data integrity. The on-chain evidence storage module performs window analysis on the continuously generated monitoring data stream and extracts key physiological features. Combined with hash operation, it achieves tamper-proof evidence storage, ensuring the authenticity and anti-counterfeiting of emergency data in the process of sharing and tracing, thus laying a reliable foundation for subsequent secure access.

[0015] (2) The blockchain-based obstetric and gynecological emergency medical data security sharing system, through the smart contract mechanism of the emergency access token management module, can generate temporary tokens by combining proxy decision voting when emergency doctors make emergency requests, realize flexible dynamic authorization, and effectively shorten the authorization link response time; at the same time, the security decryption and data sharing module can generate layered decryption keys according to access permissions and perform layer-by-layer verification, avoid unnecessary full decryption operations, improve decryption efficiency, and realize data consistency verification through hash comparison, ensuring the security and reliability of shared data in emergency scenarios.

[0016] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0017] Figure 1 This is a flowchart of the blockchain-based obstetric and gynecological emergency medical data security sharing system of the present invention. Detailed Implementation

[0018] This application embodiment solves the problems of insufficient privacy protection, low access efficiency, and inflexible authorization mechanism in the secure sharing of medical data among multiple institutions in obstetric and gynecological emergency scenarios by using a blockchain-based obstetric and gynecological emergency medical data security sharing system.

[0019] The overall approach of the solution in this application is as follows: a data hierarchical desensitization module is set up to achieve differentiated protection of sensitive information; an on-chain evidence storage module is used to ensure the integrity and traceability of emergency monitoring data; an emergency access token management module is combined to achieve a dynamic authorization mechanism; and finally, a secure decryption and data sharing module is used to ensure layered decryption and consistency verification of data. This approach ensures privacy and security while meeting the needs for rapid data sharing and high reliability in emergency situations.

[0020] Please see Figure 1 This invention provides a technical solution: a blockchain-based obstetric and gynecological emergency medical data security sharing system, comprising the following modules: a data grading and desensitization module, used to establish multi-level desensitization rules based on the sensitivity differences of obstetric and gynecological emergency data, perform desensitization and replacement processing on patient personal identifiers according to the multi-level sensitivity rules, and simultaneously grade and identify the medical data itself, outputting graded and desensitized obstetric and gynecological emergency medical data; and an on-chain evidence storage module, used to receive desensitized emergency data with grading identifiers, perform window processing on the continuously generated monitoring data stream, extract key physiological feature values ​​within each time window and calculate their feature value hashes, combine the feature value hashes with the data grading identifiers to generate a data feature descriptor, and submit the hash value of the descriptor as an evidence storage transaction to the blockchain network. The system comprises: a network; an emergency access token management module, which receives emergency access requests from paramedics via smart contracts deployed on the blockchain, notifies the patient's pre-defined decision-makers and starts a timer, and generates a temporary access token associated with a data feature descriptor hash value after obtaining proxy votes that meet preset rules; and a security decryption and data sharing module, which verifies the requester's access rights and the validity of the temporary access token and generates a hierarchical decryption key. Based on the data feature descriptor obtained from the blockchain, it retrieves the corresponding encrypted data from the distributed storage system, performs decryption using the hierarchical decryption key, recalculates the feature value hash of the decrypted data, compares it with the original feature value hash stored on the blockchain, and shares the data with the authorized party and records the operation log after successful verification.

[0021] In this implementation plan, the data grading and desensitization module provides differentiated protection for different categories of obstetric and gynecological emergency medical data. Since emergency data contains both direct patient identification information (such as name and ID number) and sensitive medical parameters (such as fetal heart rate and uterine contractions), multi-level desensitization rules are needed based on the sensitivity of the data. "Desensitization" refers to processing the original data through encryption, disguise, and range division to reduce the risk of privacy leakage. During processing, this module irreversibly replaces highly sensitive personal identifiers (e.g., generating irreversible pseudo-identifiers through hash calculations), while for some sensitive data that still requires clinical analysis, numerical range division or format preservation encryption methods are used, ensuring that the data maintains clinical usability while protecting privacy. Finally, this module outputs desensitized data with grading labels for subsequent tracking and retrieval. The on-chain evidence storage module ensures the integrity and immutability of emergency data. "Evidence storage" refers to hashing key information (not the data itself) to form a digest and writing it into the blockchain ledger for subsequent verification. Specifically, this module performs windowing processing on the continuously generated monitoring data stream, dividing the data into several segments according to certain time intervals. Key physiological characteristics are extracted within each time window, such as fetal heart rate variability, uterine contraction pressure curve morphology, and maternal circulatory indicators. These characteristics are then hashed into unique "feature value hashes" using a hash algorithm. For subsequent retrieval and tracking, this module combines the feature value hashes with data hierarchical identifiers to generate "data feature descriptors." A "descriptor" is a structured set of information 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 retrieval can be verified for authenticity through on-chain comparison. The emergency access token management module enables 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 requester has access rights within a specific time frame. In practical applications, emergency physicians can initiate emergency access requests through smart contracts, and the system will automatically send notifications to the patient's pre-set decision-makers and start a timer. The system generates a temporary access token corresponding to the data feature descriptor only when the agent completes the voting agreement according to the rules. This mechanism ensures data availability during emergency situations while preventing unauthorized access. The secure decryption and data sharing module implements layered decryption and consistency verification to ensure that shared data is both secure and reliable. In practice, the requesting party must first submit a temporary access token. After verifying its legitimacy, the system assigns different levels of decryption keys based on the data's sensitivity. "Layered decryption" means that data of different sensitivity levels must be decrypted using different strengths to prevent low-privilege users from excessively accessing highly sensitive data.Subsequently, the system retrieves the corresponding encrypted data from the distributed storage system based on the data feature descriptor on the blockchain and performs decryption. After decryption, the system recalculates the data's feature value hash and compares it with the hash already stored on the blockchain to verify that the data has not been tampered with during storage and transmission. Only after successful verification will the system share the data with the authorized party and automatically record operation logs for traceability.

[0022] Specifically, the logic for establishing multi-level desensitization rules based on the sensitivity differences of obstetric and gynecological emergency data is as follows: Different data types in the obstetric and gynecological emergency data are identified and divided into four categories: personal identifiers, quasi-identifiers, sensitive medical data, and general medical data. According to 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. A corresponding desensitization processing intensity is configured for each sensitivity level. Specifically, the first sensitivity level is configured with irreversible hash algorithm replacement processing, the second sensitivity level with format preservation encryption processing, the third sensitivity level with numerical interval processing based on a preset threshold range, and the fourth sensitivity level with minimization processing based on key field removal. A mapping relationship between sensitivity levels and desensitization processing intensity is established, forming a multi-level desensitization rule system.

[0023] In this implementation plan, firstly, emergency medical data is categorized, identifying different data types, including: Personal identifiers: such as name, ID number, contact information, etc., which directly point to the patient's identity; Quasi-identifiers: such as hospital number, date of birth, address, etc., which may not identify the patient when used alone, but can be inferred when combined with other information; Sensitive medical data: such as fetal heart rate curves, uterine contraction intensity, past delivery history, etc., involving maternal and infant health status; General medical data: such as examination time, department category, routine test values, etc., with lower privacy sensitivity. Secondly, according to the data sensitivity level from high to low, four sensitivity levels are set: First sensitivity level (highest): Personal identifiers; Second sensitivity level: Quasi-identifiers; Third sensitivity level: Sensitive medical data; Fourth sensitivity level (lowest): General medical data. Then, corresponding de-identification processing methods are configured for different sensitivity levels: The first level uses irreversible substitution processing with a hash algorithm. A hash is a one-way function that can convert identity information into a fixed-length pseudo-identifier, making it impossible to deduce the original identity from the result, thus protecting the patient's identity to the greatest extent. The second level uses format-preserving encryption processing. This encryption method preserves the original data format; for example, dates are still displayed as dates, but the specific numerical values ​​are encrypted and replaced, protecting privacy while maintaining system compatibility. The third level employs threshold-based numerical range processing. For example, specific fetal heart rate values ​​are converted into ranges such as "normal range," "high," and "low," instead of directly exposing the precise value, thereby reducing the risk of sensitive information leakage while retaining clinical judgment value. The fourth level uses minimal processing by removing key fields. For example, minutes and seconds are removed from timestamps, retaining only the date, eliminating unnecessary fine-grained information, and reducing redundant privacy exposure. Finally, a mapping relationship between sensitivity levels and desensitization processing intensity is established through the above rules, forming a complete multi-level desensitization system. In this way, data with different sensitivities will employ differentiated protection strategies when shared, meeting the clinical needs of emergency physicians while maximizing patient privacy and security.

[0024] Specifically, the 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: 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 tags 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; and the complete data packet is signed and verified using an asymmetric key digital signature algorithm, outputting graded desensitized obstetric and gynecological emergency medical data. In this implementation scheme, the personal identifier desensitization process irreversibly replaces personal identifiers belonging to the first sensitivity level. Specifically: for identifiers... Perform a hash function calculation to obtain a pseudonym. ;in: Original personal identifier; The default SHA-256 hash function is used, which has one-way and collision resistance. The generated pseudonym. This process ensures that the original identifier cannot be recovered by reverse computation. The quasi-identifier encryption process will process the quasi-identifier data, which belongs to the second level of sensitivity. Perform format-preserving encryption to obtain the encrypted result. ;in: Primitive quasi-identifier; Asymmetric encryption function based on AES algorithm; The dynamically generated symmetric encryption key is determined by a random number generator and a seed parameter; The encrypted quasi-identifier. Key The generation method is as follows: ;in: : System random number; Safe seeds; Key derivation function. Sensitive medical data range processing will process sensitive medical numerical data belonging to the third sensitivity level. Convert to range value ;in; Original sensitive medical data; : A set of preset thresholds used to define interval boundaries; A range mapping function maps raw numerical values ​​to corresponding range labels; Range-divided numerical labels. Threshold set. The method for determining this is based on the historical sample distribution, using the quantile method: ;in: Historical sample sets of similar sensitive medical data; Quantitation function, according to the proportion b Divide the data distribution; The resulting threshold set. Minimization processing of general medical data at the fourth sensitivity level. Remove keyword fields and retain only essential contextual information to obtain minimized data. This processing does not involve calculations; it directly removes specified fields from the structured data. Hierarchical labels and data are encapsulated into all processed data elements. Add corresponding sensitivity level tags, repackage according to the emergency rescue event timeline, and form a data packet. Metadata appended with signature verification in the data packet Add metadata This includes generating a timestamp and processing organization information; subsequently, an asymmetric key signature algorithm is used to sign the complete data packet: ;in: Graded and desensitized medical data packages; Metadata; splicing operation; Private key for signing; The generated digital signature. The receiving end uses the corresponding public key. Verification required: If verification is successful, the data packet can be safely used for emergency response decisions.

[0025] Specifically, the 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 feature 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 feature 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 feature value hash is generated using a hash algorithm.

[0026] In this implementation plan, the time window segmentation is based on the clinical characteristics of obstetric and gynecological emergency monitoring data, and the time window length is set adaptively. 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 is 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 The stable range can be determined based on clinical criteria. The longest duration during which consecutive sampling points fall within the safe range represents the stability of physiological parameters. Multidimensional feature vector construction and normalization combine the above statistical features with time window labeling information. ;right Perform normalization processing (such as Min-Max or Z-score) to generate standardized multidimensional feature vectors. Eigenvalue hashing generates irreversible eigenvalue hashes from normalized eigenvectors using a hash algorithm. The `Hash()` function employs the SHA-256 irreversible hash algorithm to ensure that the feature value hash corresponding to each time window is unique and tamper-proof. In actual obstetric and gynecological emergency scenarios, when a pregnant woman experiences abnormal uterine contractions or fetal heart rate fluctuations, the system receives a continuous vital sign data stream that has undergone graded 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 characteristics, uterine contraction pressure curve morphology, and maternal circulatory function indicators, while simultaneously calculating statistical feature quantities by combining 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 continuously monitored data.

[0027] Specifically, the 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.

[0028] In this implementation scheme, a mapping table is established to construct a mapping relationship between feature value hashes and data hierarchical identifiers. For each data sample, let its feature value hash be... The classification is marked as Then the mapping function is defined as: ;in, : The hash of the feature value calculated from the original data; The hierarchical identifier corresponding to this 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 employs a combination strategy based on hashing and XOR operations, ensuring that different versions of the same data can be distinguished. In obstetric and gynecological emergency scenarios, the system extracts feature value hashes from continuously monitored desensitized vital sign data and graded sensitive medical data, combining them with corresponding graded identifiers to generate standardized data feature descriptors. By adding timestamps, data type information, version numbers, and integrity check codes, the system ensures that each descriptor uniquely identifies the corresponding data and allows for tracing its generation and processing. The unique content identifier generated after serialization and encoding is bound to the original data storage path and submitted for evidence storage through blockchain nodes, achieving tamper-proof protection for data integrity and security. This processing step enables rapid verification of data authenticity and integrity in emergency environments, providing a reliable basis for subsequent secure sharing and authorized access. It also ensures that even if multiple versions of data exist, they can be accurately distinguished and tracked through check codes, improving the credibility and operational efficiency of medical data management.

[0029] Specifically, the emergency access token management module includes the following steps: receiving emergency access requests submitted by emergency physicians through a smart contract interface deployed on the blockchain. These requests include the physician's identity credentials, the patient's medical record identifier, and the hash value of the data feature descriptor requested for access. After verifying the physician's legitimacy, an access authorization request notification is sent to at least two pre-selected decision-makers, while simultaneously starting a configurable timer to set a voting decision time window. The module receives and verifies the digital signature voting responses of the decision-makers in real time through the smart contract's vote collection mechanism. When a vote conforming to the pre-selected multi-signature rules is obtained before the timer expires, a time-limited temporary access token is generated and bound to the hash value of the data feature descriptor in the request. The access permission status on the blockchain is updated, and the token generation event is recorded in the distributed ledger. The temporary access token is then securely distributed to the requesting physician through an event push mechanism.

[0030] In this implementation, the emergency access request is received from the emergency physician via a smart contract interface deployed on the blockchain. The request comprises three parts: the physician's identity credentials, the patient's medical record identifier, and the feature descriptor hash value of the target data. The identity verification smart contract uses the doctor's public key registered on the blockchain to verify their identity credentials. If a match is found, the authorization process begins. This only involves digital signature verification. After successful identity verification, the system sends an access authorization request notification to at least two pre-selected decision-makers (the patient's designated agents) and simultaneously starts a configurable timer. The set time window is... Within this timeframe, vote collection must be completed. The agent decision-maker generates a digitally signed vote using their private key and submits it to the smart contract, collecting and verifying the vote responses. Let the set of votes collected by the system be: ;in, :No. The voting result of the proxy decision-makers is 1 for agreement and 0 for rejection; : within the time window The number of proxies who have submitted valid votes. The smart contract needs to determine whether this set satisfies the multi-signature rule. Let the rule threshold be... The determination condition is: ;in, :No. The weighting coefficient of the agent decision-maker; : Voting value (1 for agreeing, 0 for disagreeing); Weighted voting score; Voting threshold. Weighting coefficient. The determination method is based on the patient's initial authorization level definition, for example, a voting weight of 1.0 for immediate family members, 0.8 for the attending physician, and 0.5 for other agents. Threshold. The method for determining this is as follows: It can be defined as a fixed proportion of the total weights, for example, setting a threshold of 60% of the total weights, i.e.: , ;in This is a scaling factor, specified by the patient in a preset strategy. A temporary access token is generated during the time window. The internal condition is satisfied. At that time, the system generates a temporary access token with a time limit. Its generation method can be represented as: ;in, : The hash value of the data feature descriptor submitted in the request; : A random number generated by a smart contract to prevent token replay; Token expiration timestamp; : Secure hash function; : Indicates a connection operation. Binding and recording will generate a token. With data feature descriptor hash value The token is bound and the access permission status on the blockchain is updated. Simultaneously, the token generation event is recorded in the distributed ledger to ensure full traceability. Secure distribution of the temporary access token is achieved through an on-chain event push mechanism. Distributed to the requesting doctor. The doctor can use the token after the expiration time. Access patient-specified data internally.

[0031] Specifically, the 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: The requester submits access credentials and a temporary access token; the validity period and digital signature authenticity of the token are verified through a blockchain smart contract; the token status information recorded on the blockchain is queried to confirm that the token has not been used and matches the hash value of the requested data feature descriptor; the medical role attributes contained in the requester's digital identity certificate are verified to meet the access permission level requirements of the data classification identifier; a hierarchical decryption key structure is generated based on the temporary access token and the requester's attribute information using a multi-level key derivation function, which includes 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 according to the content identifier in the data feature descriptor; encrypted data packets are obtained from the distributed storage node through a secure transmission protocol, and the integrity signature of the data packets is verified.

[0032] In this implementation plan, the system for receiving and verifying access credentials first receives the access credentials and temporary access token submitted by the requester. The process involves calling a blockchain smart contract to verify if the token's validity period is within the expiration timestamp; verifying the authenticity of the token's digital signature; and querying the token's status recorded in the blockchain ledger to ensure that the token has not been used and that its hash value matches the target data feature descriptor. Consistency. This step ensures that the access credentials are legitimate and have not been tampered with. Access permission verification verifies the medical role attributes contained in the requester's digital identity certificate. Determine whether it meets the data classification criteria. The corresponding access permission level requirements. The determination rule formula can be expressed as: ;in, The permission determination result has a value of 1 indicating approval and 0 indicating denial. : The set of role attributes of the requester; Data classification identifies the corresponding access level; If the request is accepted, the system proceeds to the key generation step; otherwise, the request is rejected. A multi-layered decryption key is generated. Based on the temporary access token and the requester's attribute information, the system executes a multi-layered key derivation function. This generates a layered decryption key structure. The formula is: ;in, : The derived first Layer decryption key; Temporary access token; : Attributes of the requester; The system random factor is used to ensure the uniqueness of keys across different sessions. Multi-level key derivation function; : Concatenation operator. A hierarchical key structure includes: a base key. : Used to decrypt metadata (timestamps, signatures, and other basic information); Content key This layer is used to decrypt specific medical data content; other layers can be extended to support fine-grained access control. Content identifier location and ciphertext retrieval are based on the content identifier in the data feature descriptor. The corresponding encrypted data block is located in the distributed storage system. The storage node location is found using a distributed index table; a secure transport protocol (such as TLS or link encryption protocol) is initiated to request the encrypted data packet. Integrity verification is performed on the integrity signature of the received encrypted data packet. Let the received data packet be... The signature is The verification function is: ;in, The verification result is 1 if it passes and 0 if it fails. : Received encrypted data packets; Data integrity signature; The public key of the storage node; Signature verification function. Only when... Only when this condition is met will the system allow subsequent decryption operations.

[0033] Specifically, the process involves decryption using a layered decryption key, recalculating the feature hash of the decrypted data, comparing it with the original feature hash stored on the blockchain, and sharing the data with the authorized party after successful verification, while also recording the operation log. The specific steps are as follows: First, 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 structural information. Then, the corresponding decryption algorithm is selected based on the encryption scheme identifier in the metadata, and the specific medical data content is decrypted using the content key. The original decrypted medical data undergoes feature extraction again, and a verification feature hash is generated according to the same windowing processing and feature value calculation rules as during evidence storage. The newly generated feature hash is then compared bit-by-bit with the original feature hash stored on the blockchain to verify data integrity and consistency. Finally, after successful verification, the decrypted medical data is shared with the authorized party through a secure data channel, while limiting the duration and scope of data usage.

[0034] In this implementation scheme, the metadata decryption system first utilizes the base key from the hierarchical decryption key. Decrypt the metadata portion of the data packet to obtain the encrypted parameters. and structural information This step ensures that the correct decryption algorithm and parsing rules are selected subsequently. Based on the encryption scheme identifier in the metadata, the system selects the corresponding decryption algorithm to decrypt the medical data. The content key from the hierarchical decryption key is then used. The medical data subject is decrypted to obtain the original medical data stream. Feature parameters are extracted using the same windowing process and feature value calculation rules as during evidence preservation, forming a feature vector. The characteristic parameter calculation can be expressed as: ;in: Rate of change of trend; Abnormal fluctuation range; Other statistical characteristics, such as the stable interval range, are also considered. After obtaining the feature vector, the system executes a normalization function. Generate standardized vectors Then through a hash function Calculate the hash of the feature value used for verification: ;in: : The newly generated feature value hash; : Normalized feature vectors; : The timestamp sequence of the window; : Structural information in metadata; Hash functions are used to generate fixed-length digests. : Indicates a join operation. The blockchain hash comparison will generate a feature value hash. Compared with the original feature value hash stored on the blockchain Perform a character-by-character comparison. The comparison formula is: ;in: :Difference count; The total bit length of the hash value; The newly generated hash Bit; The first blockchain evidence hash Bit; Bit comparison function, if Then take 0, otherwise take 1. When Upon successful verification of data integrity and consistency, the system determines that the data sharing and usage are restricted. After successful verification, the system will transfer the decrypted medical data through a secure data channel. Send to the authorized party. Simultaneously, based on preset policy control parameters. This limits the duration and scope of data usage. The control strategy can be expressed as: ;in: Data sharing control results; Decrypted medical data; :A set of limiting parameters, including maximum usage duration and usage scope; The policy execution function is used to prune, mask, or periodically destroy data. The decryption process explains in detail how layered decryption is achieved using the base key and content key. The comparison formula uses bit-by-bit difference counting. It means that only when Only then can verification be passed. Data sharing and restrictions are controlled by a function. It discloses how to limit the duration and scope to prevent the data from being overused.

[0035] In summary, this application has at least the following effects: This blockchain-based obstetrics and gynecology emergency medical data security sharing system achieves refined management and rapid retrieval of sensitive information through hierarchical data anonymization and feature-value hash notarization. This enables emergency physicians to quickly obtain the necessary data in emergency situations, significantly improving the timeliness of emergency decision-making. Employing multi-level anonymization rules, layered encryption, and temporary access token mechanisms, combined with the immutability of blockchain, the system ensures the security and traceability of patient personal information and medical data during sharing and storage. Through smart contracts and multi-signature proxy decision-making mechanisms, dynamic authorization and real-time monitoring of emergency access are achieved, ensuring that data sharing meets emergency needs while restricting access permissions and scope of use. Layered decryption, feature-value hash comparison, and secure data channel transmission enable integrity verification of shared data, ensuring that the data obtained by the authorized party is consistent with the notarized data and is reliable and usable. The system design also considers multi-institutional data collaboration, supporting distributed storage and blockchain network expansion, enabling secure and efficient sharing and retrieval of obstetrics and gynecology emergency data among different medical institutions.

[0036] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0037] This invention is described with reference to flowchart illustrations and / or block diagrams of systems, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams.Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0038] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0039] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0040] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0041] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

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.

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 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.

5. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 4, characterized in that: 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.

6. The blockchain-based obstetric and gynecological emergency medical data secure 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.

7. The blockchain-based obstetric and gynecological emergency medical data security sharing system according to claim 6, 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.

8. The blockchain-based obstetric and gynecological emergency medical data secure sharing system according to claim 7, 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