Standardized management and privacy protection method for medical health data

Abstract

The invention discloses a standardized management and privacy protection method for medical health data, and relates to the technical field of data protection. Comprising the steps of S1, adding noise data in an original data set, obtaining a noise data set, and performing preprocessing and classification; s2, encrypting the preprocessed data through an end-to-end encryption algorithm, storing the preprocessed data through a block chain, and performing data sharing under a preset condition; and S3, monitoring the application range and path of the medical data through the management module, and protecting the privacy data through the real-time monitoring module. According to the method, whether the access authority is granted or not can be automatically determined according to the predefined rule, the accessible data range and the service life are specified, the operation process is recorded in a log operation mode, and a non-tampering log chain is formed, so that the data sharing process is simplified, the transparency of data sharing is ensured, and the data sharing efficiency is improved. The possibility of human intervention is reduced, and the operation risk is reduced.

Description

Technical Field

[0001] The present invention relates to the field of data protection technology, and specifically to a method for standardized management and privacy protection of medical and health data. Background Art

[0002] With the development of the "Internet + Medical" model, the value of personal health and medical information has become increasingly prominent. This information not only includes the data contained in traditional paper medical records, but also extends to multiple dimensions such as electronic health records (EHR), genetic information, and medical laboratory results. However, this diverse and complex data type also brings new security risks, such as data leakage and illegal access, which poses a serious threat to patient privacy.

[0003] The Chinese invention patent with publication number CN115618412A discloses a medical privacy data protection method based on blockchain, which sends medical privacy data to the HDFS distributed file management system, performs ring signature processing on the medical privacy data, and the HDFS distributed file management system synthesizes the Hash, timestamp and storage location index information of the medical privacy data into a transaction record of the blockchain system and sends it to the blockchain system. This method supports distributed cluster storage of blockchain nodes, provides data fault tolerance and reliability guarantee, and realizes the consistency consensus and tamper-proof of blockchain medical privacy data based on the HDFS distributed file management system and ring signature medical privacy data chain method. Blockchain technology is used to realize medical privacy data protection, and massive medical privacy data is distributed and encrypted for storage, which reduces the possibility of leakage and tampering of patient medical privacy data while reducing the storage pressure of the blockchain system.

[0004] In the process of interconnecting and communicating medical data, the above-mentioned and similar management systems have poor interoperability of information systems among medical institutions, which not only hinders effective data exchange, but also increases potential security threats caused by data transmission. Summary of the invention

[0005] The purpose of the present invention is to provide a standardized management and privacy protection method for medical health data to solve the problems raised in the above background technology.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a standardized management and privacy protection method for medical and health data, comprising:

[0007] S1: Obtain preprocessed data: add noise data to the original data set, obtain a noise data set, and preprocess and classify the noise data set;

[0008] S2: Data encryption transmission: The pre-processed data is encrypted using an end-to-end encryption algorithm, and after being stored on the blockchain, the pre-processed data is shared under preset conditions;

[0009] S3: Data interaction management: Monitor the application scope and channels of medical data through the management module, and protect privacy data through the real-time monitoring module;

[0010] The pre-processed data is shared under preset conditions, including:

[0011] S2.1: Data encryption using end-to-end encryption algorithm: Set a key rotation strategy and encrypt the pre-processed data using hybrid encryption;

[0012] S2.2: Chain-by-chain operation log recording: the operation log is divided and pre-processed, and the pre-processed operation log is saved through the blockchain and the side chain / lightning network;

[0013] S2.3: Condition-triggered sharing of data: By dynamically adjusting the rules, the saved operation log is called, and the calling process is verified through multi-factor authentication.

[0014] Furthermore, the noise data set is preprocessed and classified, including:

[0015] S1.1: Obtain a noise data set: set the sensitivity and privacy parameters of the data, and set noise data in the original data set according to the sensitivity and privacy parameters;

[0016] S1.2: Data preprocessing: in the noise data set, direct identifiers and quasi-identifiers are determined, the direct identifiers are deleted, and the quasi-identifiers are generalized or perturbed;

[0017] S1.3: Data classification: Classify the preprocessed noise data set according to a five-level classification system.

[0018] Furthermore, the sensitivity is set by querying the object, specifically:

[0019] When the query object is a single query, the sensitivity is set to 1;

[0020] When the query object is a sum query, the sensitivity is set according to the maximum value of a single entry;

[0021] When the query object is a complex query, the sensitivity is set according to the maximum change in the original data set in the worst case.

[0022] Furthermore, the preprocessed data is encrypted, including:

[0023] M1: Setting a key rotation strategy: Setting a time window, and updating the session key based on the time window;

[0024] M2: Set hybrid encryption mode: verify the user identity through asymmetric encryption, encrypt the shared key through symmetric encryption, and obtain the decrypted pre-processed data.

[0025] Furthermore, the decrypted pre-processed data is obtained, including:

[0026] M2.1: Encrypt the sender's random session key using the receiver's public key, and decrypt the encrypted random session key using the private key corresponding to the public key to obtain a decrypted session key;

[0027] M2.2: Encrypt the preprocessed data using the decryption session key to obtain an encrypted data set, and send the decryption session key and the encrypted data set to a recipient;

[0028] M2.3: Decrypt the decryption session key using the recipient's private key, decrypt the encrypted data set, and obtain the decrypted preprocessed data.

[0029] Furthermore, the pre-processed operation log is saved, including:

[0030] W1: Log structure design: compress the operation log by batch processing or summary form, and set the metadata field for the compressed operation log by adding the metadata field;

[0031] W2: Log partition storage: According to the metadata field, the compressed operation log is divided into critical logs, frequent but non-critical logs and small interaction logs with low immediacy requirements, and the critical logs are stored in the blockchain, the frequent but non-critical logs are stored in the side chain, and the small interaction logs with low immediacy requirements are stored in the lightning network.

[0032] Furthermore, the calling process is verified, including:

[0033] N1: Set dynamic adjustment rules: Dynamically adjust the rules in the smart contract through weighted voting mechanism, setting time windows and cooling periods, and establishing circuit breaker mechanisms;

[0034] N2: Perform multi-factor authentication: Perform multi-factor authentication for data transmission through dynamic MFA policies, continuous identity authentication, and trust scoring systems.

[0035] Furthermore, the rules in the smart contract are dynamically adjusted, including:

[0036] N1.1: Set up a weighted voting mechanism: Obtain the relationship between each participant’s voting weight and the total number of votes through the total number of votes threshold and the total number of votes participating in the vote. Specifically:

[0037]

[0038] Where: V i is the voting weight of the ith participant, T is the total vote threshold, M is the total number of people participating in the vote, and i is the participant index;

[0039] N1.2: Set the time window and cooling period: Get the relationship between two consecutive proposals by setting the time window length and cooling period length, specifically:

[0040]

[0041] in: For Proposal P t+1 Submission time, For Proposal P t The submission time, W is the time window length for proposal submission, P is the length of the cooling period, and P t is the tth proposal, P t+1 is the t+1th proposal;

[0042] N1.3: Set up an automatic fuse mechanism: Use the preset safety threshold to judge the status indicators of the current system, specifically:

[0043] When the state indicator is greater than a preset safety threshold, the automatic fuse mechanism is operated, otherwise the current system maintains the current operating state and continues to operate.

[0044] Furthermore, multi-factor authentication is performed on data transmission, including:

[0045] N2.1: Dynamic MFA policy authentication: Obtain risk scores based on geographic deviation, device fingerprint similarity score, and the difference between login time and normal patterns, specifically:

[0046] R=ω1·G+ω2·D+ω3·T

[0047] Where: R is the risk score, G is the degree of geographic deviation, D is the device fingerprint similarity score, T′ is the difference between the login time and the normal mode, ω1 is the weight of the degree of deviation, ω2 is the weight of the similarity, and ω3 is the weight of the difference;

[0048] N2.2: Continuous authentication: Monitor user behavior during the session;

[0049] N2.3: Establish a trust scoring system: Obtain trust scores based on behavior records, specifically:

[0050] S=S0+n p ΔS p -n n ΔS n

[0051] Where: S is the trust score, S0 is the initial trust score, n p is the number of positive events, ΔS p Increased trust score for positive events, n n is the number of negative events, ΔS n Trust score for negative events.

[0052] Furthermore, privacy data is protected, including:

[0053] S3.1: Monitoring the application scope and channels of data: Through the management module, the number of accesses, authorized objects, application scope and channels of the medical data are monitored and managed;

[0054] S3.2: Abnormal monitoring and early warning: The real-time monitoring module is used to monitor the calling process of the privacy data and obtain the status indicators of the system at the current moment. The status indicators are compared with the preset safety thresholds. According to the comparison results, the triggering state of the alarm signal is determined, which is specifically:

[0055] When the state indicator is greater than a preset safety threshold, the alarm signal is triggered, otherwise the alarm signal is not triggered.

[0056] Compared with the prior art, the present invention has the following beneficial effects:

[0057] First, the present invention uses a data sharing mechanism driven by smart contracts to automatically decide whether to grant access rights according to predefined rules, specify the scope of accessible data and the period of use, and record the operation process in the form of operation logs to form an unalterable log chain, thereby not only simplifying the data sharing process, but also ensuring the transparency of data sharing, reducing the possibility of human intervention, and reducing operational risks;

[0058] Second: The present invention uses a real-time monitoring system and preset security thresholds to enable it to detect and respond to potential threats in the first place. That is, once abnormal behavior or operations beyond the normal range are detected, a warning can be issued and relevant personnel can be notified to take action, which helps to quickly locate the source of the problem and take measures to solve it, thereby minimizing losses;

[0059] Third: Through the management module, the present invention enables patients to monitor the users and specific uses of their medical data in real time, and can adjust the sharing settings according to personal wishes, thereby greatly enhancing the autonomy of patients and making them core participants in the management of their own health information. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 It is a flowchart of the standardization management and privacy protection method in the present invention;

[0061] Figure 2 A schematic diagram of the process of obtaining a preprocessed noise data set in the present invention;

[0062] Figure 3 A schematic diagram of the process of obtaining decrypted pre-processed data in the present invention;

[0063] Figure 4 It is a flowchart of verifying the calling process in the present invention. DETAILED DESCRIPTION

[0064] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0065] In the process of interconnecting and communicating medical data, the existing management system has poor interoperability of information systems between medical institutions, which not only hinders effective data exchange, but also increases potential security threats caused by data transmission. The technical solution of this application builds a comprehensive security framework by integrating multi-factor authentication, smart contract-driven data sharing, patient self-management module and real-time monitoring and early warning system, and classifies and stores data through blockchain, side chain and lightning network, and combines differential privacy and zero-knowledge proof to ensure the security and privacy of data transmission and use. At the same time, patients can monitor and control the application scope and channels of their own medical data in real time through the management module, and can timely discover and respond to potential threats through the real-time monitoring module, which not only enhances the autonomy of patients, but also improves the security and compliance of data processing.

[0066] refer to Figure 1-Figure 4 The present application provides a standardized management and privacy protection method for medical health data, which includes the following steps:

[0067] Step S1: Obtain preprocessed data. That is, by using the differential privacy algorithm, add the corresponding noise data to the original data set to obtain the noise data set. At the same time, the noise data set is preprocessed accordingly (i.e., de-identification and personal information anonymization), and the noise data set is classified according to the five-level classification system. The details are as follows:

[0068] Step S1.1: Get a noise data set. That is, according to the original data set, set the sensitivity and privacy parameters of the data, and add the corresponding noise data to the original data set according to the set sensitivity and privacy parameters. In this embodiment, in the process of setting the data sensitivity, it is set according to the data set and the query object. Specifically, when the query object is a single query, that is, a simple counting query (such as counting the number of occurrences of a certain disease), the data sensitivity is set to 1. When the query object is a sum query (such as calculating the total cost, total drug dosage, etc.), it is set according to the maximum value of a single entry. When the query object is a complex query (such as mean, variance or other aggregate functions), it is set according to the maximum change in the worst case in the original data set. It is worth noting that the setting of the privacy parameters in this embodiment can be specifically set according to the specific use of the object, so it is not specifically explained in this embodiment.

[0069] In the specific implementation process, when a report on the incidence of diabetes in region A is released, the query object is a single query in the process of processing the original data set, that is, the data sensitivity is set to 1. Furthermore, when analyzing the effect of new drug B, it involves the interaction between multiple variables, that is, the query object is a complex query. Specifically, at this time, the focus is on the variation range of the efficacy score of new drug B, and the variation range of the efficacy score of the drug is 0-10 points, so the data sensitivity is set to 10.

[0070] Furthermore, in this embodiment, according to the set sensitivity and privacy parameters, corresponding noise data is added to the original data set through Laplace distribution or Gaussian distribution. Specifically, when the original data set is a simple query, such as count or average, random noise data is generated through Laplace distribution. When the original data set is a multidimensional data analysis, random noise data is generated through Gaussian distribution.

[0071] Step S1.2: Data preprocessing. That is, after adding noise data, the data set is further preprocessed, including but not limited to removing identity information that can be directly associated with an individual (such as name, ID number, etc.), and generalizing or perturbing other information that may indirectly identify an individual (such as date of birth, zip code, etc.), and enhancing the privacy protection level of the data set through advanced privacy protection models (such as k-anonymity, l-diversity).

[0072] In this embodiment, direct identifiers (such as name and ID number) and quasi-identifiers (such as date of birth, postal code and gender) are identified from the noise data set obtained in step S1, and the direct identifiers are deleted. The quasi-identifiers are reduced in recognition through generalization or perturbation, such as converting a specific date of birth into an age range and masking some digits of the postal code.

[0073] In the process of specific implementation, a hospital bill database containing basic patient information (age, gender), disease diagnosis code (ICD-10) and treatment cost details is set up. At the same time, in the process of specific data processing, it is necessary to publish a report on common diseases in area C, so the data preprocessing process at this time is as follows:

[0074] De-identification: Delete all information fields that can directly point to personal identity (such as name, ID number), and modify the remaining information so that after the modified information is combined with other public information, personal information cannot be obtained.

[0075] Quasi-identifier processing: Convert the specific date of birth into an age range (such as 30-40 years old), retain the first 4 digits of the postal code, and blur the remaining digits to reduce the possibility of indirect identification.

[0076] Step S1.3: Data classification. That is, the pre-processed data set in step S1.2 is classified according to the five-level classification system. In other words, the pre-processed data set is specifically classified according to five different categories: public level, internal use level, restricted access level, strict control level and top secret level.

[0077] In the specific implementation process, when the above pre-processed data is further classified, the classification results are as follows:

[0078] Public level: Statistical results such as morbidity rate, average length of stay in hospital, etc. can be directly published to the public.

[0079] Internal use level: Statistical data, such as the distribution of incidence rates by age group, can be directly used within the hospital for reference by management personnel.

[0080] Restricted access level: Based on the needs of the research project, a more detailed original data set is required. After submitting an application and obtaining approval, the required data can be obtained.

[0081] Strict control level: Information involving patient privacy, such as specific treatment plans or drug usage, is only available to specific personnel under special conditions.

[0082] Top secret: The highest level of confidential information, such as the patient's genetic information, is handled by designated personnel after a strict approval process.

[0083] Step S2: Data encryption transmission. The classified data set obtained in step S1.3 is encrypted through an end-to-end encryption algorithm, and the operation log of the classified data set is stored through the blockchain. Through smart contracts, the classified data set can be shared under preset conditions. The details are as follows:

[0084] Step S2.1: Encrypt data using an end-to-end encryption algorithm. That is, set a key rotation strategy and encrypt data using hybrid encryption. The details are as follows:

[0085] Step M1: Set the key rotation strategy. That is, by setting a time window, the data within the time window is set with the same session key. When the time window is exceeded, the session key is updated. It is worth noting that during the update of the session key, it can be updated and exchanged through a forward-secure key update scheme (such as based on the Diffie-Hellman key exchange protocol).

[0086] Furthermore, before a user or organization accesses data, the cloud service platform will generate a pair of asymmetric keys, and at the same time, make the public key public to other authorized parties, and store the private key in the cloud. Only authenticated users can access the data. When authenticated users access encrypted data, the sender encrypts the session key using the receiver's public key, and then sends the encrypted session key together with the data encrypted with the session key to the receiver. After receiving the message, the receiver uses his or her own private key to decrypt the session key, and decrypts the actual data content with the session key, thereby obtaining the corresponding encrypted data.

[0087] In the specific implementation process, a 30-day time window is set. That is, all communications within 30 days use the same session key. When the 30-day deadline is approaching or any abnormal situation is found, a new session key will be automatically generated and the relevant parties will be notified to update accordingly.

[0088] Step M2: Set a hybrid encryption method. That is, verify the user identity through an asymmetric encryption method, and encrypt the shared key through a symmetric encryption method. Specifically, encrypt through a hybrid encryption method to obtain the decrypted pre-processed data, as follows:

[0089] Step M2.1: The sender generates a random session key K S , and the random session key K S Applied to the classified data obtained in step S1.3. At the same time, the receiver’s public key PK R For this random session key K S Encryption is performed, that is, only the recipient's public key PK R The corresponding private key SK R The random session key K S Decrypt to obtain the decryption session key E P (K S ).

[0090] Step M2.2: Decrypt the session key E P (K S ) as the key of the symmetric encryption algorithm (such as the AES-GCM algorithm), and decrypts the session key E P (K S ) The classified data set obtained in step S1.3 is further encrypted to obtain the encrypted data set C. At the same time, the decryption session key E P (K S ) and the encrypted data set C are sent to the receiver together.

[0091] Step M2.3: The receiver receives the decrypted session key E P (K S ) and the encrypted data set C, and at the same time through its own private key E P (SK R ) to decrypt the session key E P (K S ) is decrypted, thereby decrypting the encrypted data set C to obtain the decrypted data set, that is, the classified data set obtained in step S1.3.

[0092] In the specific implementation process, for each data transmission, the session key is encrypted by the receiver's public key, and then the encrypted session key is used as the key of the AES-GCM algorithm to encrypt the actual data. This not only ensures the security of data transmission, but also improves the data processing speed.

[0093] Step S2.2: Chain-by-chain operation log recording. That is, the operation log is divided and preprocessed, and the preprocessed operation log is sent to the blockchain and side chain / lightning network for storage. The details are as follows:

[0094] Step W1: Log structure design. That is, compress the operation log and extract the metadata field from the compressed operation log. In this embodiment, a large number of operation logs are compressed by batch processing or summary form. That is, for frequently occurring operation logs (such as read operations), the number of operation logs is reduced by batch processing or summary form.

[0095] In the specific implementation process, 10 read operation log entries are generated every second. And they are all accesses to the same file, so all these read operations are summarized into a comprehensive log entry within this time period. Furthermore, for the state change operation log, only the difference between the previous and next states is recorded. For example, the initial state is S0, and after several changes, the final state S n , then we only need to record the difference between the two states △S=S n -S 0。

[0096] Furthermore, after the number of operation logs is reduced, metadata fields can be added to the reduced operation logs to enable better data extraction. Specifically, the metadata fields are set according to the operation context, execution environment, and call details of the smart contract. Specifically:

[0097] When metadata fields are specifically set through the operation context, they include but are not limited to the operation type (such as read, write), the initiator identity (such as user ID), the target object (such as resource path) and any related business logic parameters. When metadata fields are specifically set through the execution environment, the specific conditions when the operation occurs are described, such as node location, network latency, hardware configuration, etc. When metadata fields are specifically set through the call details of the smart contract, for operations involving smart contracts, details such as input parameters, return values, and gas consumption can be recorded.

[0098] In the specific implementation process, when new medical record data is added to the medical health data sharing platform, in addition to the conventional timestamp and operation type, the operator's identity, the name of the medical institution, and the version number of the application used can also be attached. This metadata field helps to track the source of the data and ensure the authenticity of the information.

[0099] Step W2: Log partition storage. That is, according to the metadata fields and compressed operation logs obtained in step W1, the operation logs are classified into critical logs and non-critical logs. In this embodiment, the operation logs that directly affect the operation of the system, user rights or have legal effect are all critical logs, that is, they are stored in the blockchain. On the contrary, the remaining operation logs are all non-critical logs, that is, they are stored in the side chain / lightning network. Specifically, operation logs that occur frequently but do not directly affect the fundamental functions of the system or the direct interests of users are stored in the side chain. Operation logs with low immediacy requirements and small amounts are stored in the lightning network.

[0100] In the process of specific implementation, key logs include transaction confirmation (any log involving asset transfer, such as cryptocurrency transfer, smart contract execution results, etc.), permission changes (user identity authentication, permission granting or revocation, etc.) and compliance requirements (such as anti-money laundering checks in the financial industry, access control of medical and health data, etc.), which are stored in the blockchain. Further, frequent but non-critical logs include status updates (status reports of IoT devices, changes in player points in games, etc.), operation records (routine operations in daily business processes, such as file reading, writing, etc.), batch processing (aggregate records of multiple similar operations, such as all read operations within a period of time), which are stored in the side chain. Further, small-amount interaction logs with low immediacy requirements include small payments (social platform rewards, small-amount commodity purchases, etc.), temporary interactions (messages sent in online chat rooms, comment likes, etc.), which are stored in the lightning network.

[0101] Step S2.3: Conditional triggering of data sharing. That is, by setting dynamic adjustment rules, the saved operation log is called, and in the process of calling the saved operation log, relevant verification is performed through multi-factor authentication. The details are as follows:

[0102] Step N1: Set dynamic adjustment rules. That is, dynamically adjust the rules in the smart contract through weighted voting mechanism, setting time window and cooling period, and establishing circuit breaker mechanism. The details are as follows:

[0103] Step N1.1: Set up a weighted voting mechanism. That is, through the total vote threshold and the total number of people participating in the vote, obtain the relationship between each participant's voting weight and the total vote threshold, specifically:

[0104]

[0105] Where: V i is the voting weight of the i-th participant, T is the total vote threshold, M is the total number of people participating in the vote, and i is the participant index.

[0106] In the process of specific implementation, on a medical and health data sharing platform, different types of participants (such as medical institutions, scientific research institutions, and patient representatives) have different voting weights. When the list of authorized institutions needs to be updated, the voting weight of each participant can be obtained according to the above relationship formula, and at least 60% of the total votes are required to pass the proposal. This can not only guarantee the interests of the majority, but also avoid the monopoly of individual powerful groups.

[0107] Step N1.2: Set the time window and cooling period. That is, by setting the time window length and cooling period length, obtain the relationship between two consecutive proposals, specifically:

[0108]

[0109] in: For Proposal P t+1 Submission time, For Proposal P t The submission time, W is the time window length for proposal submission, P is the length of the cooling period, and P t is the tth proposal, P t+1 It is the t+1th proposal.

[0110] That is to say, during the specific implementation process, the submission interval between two consecutive proposals must not be less than the preset time window length and cooling-off period length, so as to avoid the potential risks brought about by repeated changes in the short term and provide sufficient time for discussion and preparation.

[0111] Step N1.3: Set up an automated circuit breaker mechanism. That is, use the preset safety threshold to judge the current system status indicators (such as trading volume, price volatility, etc.), specifically:

[0112] When the current system status indicator is greater than the preset safety threshold, the automatic fuse mechanism is activated and operates; otherwise, the system maintains the current operating state and continues to operate.

[0113] Step N2: Perform multi-factor authentication. That is, through dynamic MFA strategy, continuous identity authentication and trust scoring system, multi-factor authentication is performed during the data transmission process. The details are as follows:

[0114] Step N2.1: Dynamic MFA policy authentication. That is, the risk score is obtained through the degree of geographic deviation, device fingerprint similarity score and the difference between the login time and the normal pattern, specifically:

[0115] R=ω1·G+ω2·D+ω3·T

[0116] Where: R is the risk score, G is the degree of geographic deviation, D is the device fingerprint similarity score, T′ is the difference between the login time and the normal pattern, ω1 is the weight of the degree of deviation, ω2 is the weight of the similarity, and ω3 is the weight of the difference.

[0117] Step N2.2: Continuous identity authentication. That is, during the user's session, the user's behavior is monitored. That is, under the premise of ensuring the normal operation of the user's session behavior, the user's identity is verified (for example, entering a verification code). It is worth noting that only after the verification is passed, the user can continue the session behavior.

[0118] Step N2.3: Establish a trust scoring system. That is, according to the user's behavior record, obtain the trust score corresponding to the behavior record, and assign the trust level according to the obtained trust score. In this embodiment, only the formula for obtaining the trust score is as follows:

[0119] S=S0+n p ΔS p -n n ΔS n

[0120] Where: S is the trust score, S0 is the initial trust score, n p is the number of positive events, ΔS p Increased trust score for positive events, n n is the number of negative events, ΔS n Trust score for negative events.

[0121] In other words, by establishing a trust scoring system, the number of violations by users during data transmission can be reduced. That is, when a user violates the rules during data transmission, the corresponding trust score is low, and vice versa. Therefore, users with high trust scores can reduce the corresponding verification process according to actual needs during data transmission.

[0122] Step S3: Data interaction management. The pre-processed data obtained in step S1.3 is classified and stored in the blockchain, side chain and lightning network according to the data encryption transmission method in step S2, and the data is shared through smart contracts. At the same time, in the process of data sharing, through the set management module, patients can fully understand the application scope and path of their medical data, so that they can understand the use path of their medical data in real time, and can determine whether the data is used according to their own intentions, thereby improving the privacy protection of patients' medical data. The details are as follows:

[0123] Step S3.1: Application scope and channels of monitoring data. That is, through the management module, patients can control their own medical data, that is, patients can control the number of accesses to their medical data, authorized objects, etc. according to their own privacy, making their own medical data operable, thereby improving patients' control over their own medical data.

[0124] In the specific implementation process, patients can log in to the management module at any time through the mobile application to view the use and purpose of their medical data. For example, patient E allows the insurance company to view his medical examination report, but refuses to provide a detailed treatment plan. He can also set a time window to prohibit any non-urgent inquiries before a specific date.

[0125] Step S3.2: abnormal monitoring warning. That is, the patient's privacy data is protected through the real-time monitoring module, for example, through differential privacy and zero-knowledge proof. In this embodiment, the state indicator of the system at the current moment is obtained, and the obtained state indicator is compared with the preset safety threshold. When the state indicator is greater than the safety threshold, an alarm is triggered to notify relevant personnel to view the data and check the user's behavior. Otherwise, the user can perform related operations.

[0126] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is limited by the attached embodiments and their equivalents.

Claims

1. A standardized management and privacy protection method for medical health data, characterized in that: Included are: S1: Obtain preprocessed data: add noise data to the original data set, obtain a noise data set, and preprocess and classify the noise data set; S2: Data encryption transmission: The pre-processed data is encrypted using an end-to-end encryption algorithm, and after being stored on the blockchain, the pre-processed data is shared under preset conditions; S3: Data interaction management: Monitor the application scope and channels of medical data through the management module, and protect privacy data through the real-time monitoring module; The pre-processed data is shared under preset conditions, including: S2.1: Data encryption using end-to-end encryption algorithm: Set a key rotation strategy and encrypt the pre-processed data using hybrid encryption; S2.2: Chain-by-chain operation log recording: the operation log is divided and pre-processed, and the pre-processed operation log is saved through the blockchain and the side chain / lightning network; S2.3: Condition-triggered sharing of data: By dynamically adjusting the rules, the saved operation log is called, and the calling process is verified through multi-factor authentication.

2. The standardized management and privacy protection method for medical health data according to claim 1 is characterized in that: Preprocessing and classifying the noise data set includes: S1.1: Obtain a noise data set: set the sensitivity and privacy parameters of the data, and set noise data in the original data set according to the sensitivity and privacy parameters; S1.2: Data preprocessing: in the noise data set, direct identifiers and quasi-identifiers are determined, the direct identifiers are deleted, and the quasi-identifiers are generalized or perturbed; S1.3: Data classification: Classify the preprocessed noise data set according to a five-level classification system.

3. The standardized management and privacy protection method for medical health data according to claim 2 is characterized in that: The sensitivity is set by querying the object, specifically: When the query object is a single query, the sensitivity is set to 1; When the query object is a sum query, the sensitivity is set according to the maximum value of a single entry; When the query object is a complex query, the sensitivity is set according to the maximum change in the original data set in the worst case.

4. The method for standardized management and privacy protection of medical health data according to claim 1, characterized in that: Encrypt preprocessed data, including: M1: Setting a key rotation strategy: Setting a time window, and updating the session key based on the time window; M2: Set hybrid encryption mode: verify the user identity through asymmetric encryption, encrypt the shared key through symmetric encryption, and obtain the decrypted pre-processed data.

5. The standardized management and privacy protection method for medical health data according to claim 4 is characterized in that: Get the decrypted preprocessed data, including: M2.1: Encrypt the sender's random session key using the receiver's public key, and decrypt the encrypted random session key using the private key corresponding to the public key to obtain a decrypted session key; M2.2: Encrypt the preprocessed data using the decryption session key to obtain an encrypted data set, and send the decryption session key and the encrypted data set to a recipient; M2.3: Decrypt the decryption session key using the recipient's private key, decrypt the encrypted data set, and obtain the decrypted preprocessed data.

6. The standardized management and privacy protection method for medical health data according to claim 1, characterized in that: The pre-processed operation log is saved, including: W1: Log structure design: compress the operation log by batch processing or summary form, and set the metadata field for the compressed operation log by adding the metadata field; W2: Log partition storage: According to the metadata field, the compressed operation log is divided into critical logs, frequent but non-critical logs and small interaction logs with low immediacy requirements, and the critical logs are stored in the blockchain, the frequent but non-critical logs are stored in the side chain, and the small interaction logs with low immediacy requirements are stored in the lightning network.

7. The standardized management and privacy protection method for medical health data according to claim 1, characterized in that: Verify the calling process, including: N1: Set dynamic adjustment rules: Dynamically adjust the rules in the smart contract through weighted voting mechanism, setting time windows and cooling periods, and establishing circuit breaker mechanisms; N2: Perform multi-factor authentication: Perform multi-factor authentication for data transmission through dynamic MFA policies, continuous identity authentication, and trust scoring systems.

8. The method for standardized management and privacy protection of medical health data according to claim 7, characterized in that: Dynamically adjust the rules in smart contracts, including: N1.1: Set up a weighted voting mechanism: Obtain the relationship between each participant’s voting weight and the total number of votes through the total number of votes threshold and the total number of people participating in the vote. Specifically: Where: V i is the voting weight of the ith participant, T is the total vote threshold, M is the total number of people participating in the vote, and i is the participant index; N1.2: Set the time window and cooling period: Get the relationship between two consecutive proposals by setting the time window length and cooling period length, specifically: in: For Proposal P t+1 Submission time, is the submission time of proposal O, W is the time window length of proposal submission, P is the length of the cooling-off period, and P t is the tth proposal, P t+1 is the t+1th proposal; N1.3: Set up an automatic fuse mechanism: Use the preset safety threshold to judge the status indicators of the current system, specifically: When the state indicator is greater than a preset safety threshold, the automatic fuse mechanism is operated, otherwise the current system maintains the current operating state and continues to operate.

9. The method for standardized management and privacy protection of medical health data according to claim 7, characterized in that: Multi-factor authentication for data transmission, including: N2.1: Dynamic MFA policy authentication: Obtain risk scores based on geographic deviation, device fingerprint similarity score, and the difference between login time and normal patterns, specifically: R=ω1·G+ω2·D+ω3·T′ Where: R is the risk score, G is the degree of geographic deviation, D is the device fingerprint similarity score, T′ is the difference between the login time and the normal mode, ω1 is the weight of the degree of deviation, ω2 is the weight of the similarity, and ω3 is the weight of the difference; N2.2: Continuous authentication: Monitor user behavior during the session; N2.3: Establish a trust scoring system: Obtain trust scores based on behavior records, specifically: S=S0+n p ·ΔS p -n n ·ΔS n Where: S is the trust score, S0 is the initial trust score, n p is the number of positive events, ΔS p Increased trust score for positive events, n n is the number of negative events, ΔS n Trust score for negative events.

10. The standardized management and privacy protection method for medical health data according to claim 1, characterized in that: Protecting privacy data includes: S3.1: Monitoring the application scope and channels of data: Through the management module, the number of accesses, authorized objects, application scope and channels of the medical data are monitored and managed; S3.2: Abnormal monitoring and early warning: The real-time monitoring module is used to monitor the calling process of the privacy data and obtain the status indicators of the system at the current moment. The status indicators are compared with the preset safety thresholds. According to the comparison results, the triggering state of the alarm signal is determined, which is specifically: When the state indicator is greater than a preset safety threshold, the alarm signal is triggered, otherwise the alarm signal is not triggered.

Images