A distributed multi-dimensional health management data collection intervention system and method
By binding informed consent documents and health data to the health management system and generating anonymized identifiers, combined with access control based on roles and attributes, the problem of separating user identity from health data is solved, enabling secure personalized health services and compliant data utilization.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- WUXI XINGYUE HUIYANG TECHNOLOGY CO LTD
- Filing Date
- 2026-01-26
- Publication Date
- 2026-05-29
Smart Images
Figure CN122117198A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of health management technology and intelligent information service technology, specifically relating to a distributed multi-dimensional health management data collection and intervention system and method. Background Technology
[0002] With increasing health awareness, personal health data sources are becoming increasingly diversified, including reports from medical examination institutions, screenings at community health stations, monitoring from home smart devices, and health questionnaires completed by individuals. Currently, health management institutions generally use internal numbering to avoid directly using names when collecting this data, attempting to protect privacy. However, this method has a fatal security vulnerability: in the data collection process, the "Health Management Informed Consent Form," which contains the user's direct identification information (name, ID number, contact information), and the "Health Questionnaire," which contains health details, are usually managed physically or logically separately. Although the questionnaire uses internal numbering, if the informed consent form is accessed without authorization due to mismanagement, attackers can easily match the user's identity with their complete health data using the shared internal number between the two documents, causing a serious privacy breach.
[0003] This vulnerability leads to the following inherent defects in existing technical solutions: 1. Privacy protection is ineffective: The so-called "anonymization" or "numbering" is fragile under a management system that combines informed consent forms and questionnaires, and cannot achieve true identity segregation.
[0004] 2. Data silos and integration difficulties: Due to the aforementioned security concerns, users are unwilling to share data, and it is also difficult for organizations to securely integrate multi-source data.
[0005] 3. The conflict between data use and privacy: Institutions need health data when providing personalized services, but they cannot technically guarantee that users' identity information will not be accessed, which limits the legal and compliant use of data.
[0006] Therefore, there is an urgent need for a systematic solution that can completely isolate identity and health information from the source and support secure use. Summary of the Invention
[0007] [Technical Issues] The technical problem to be solved by this invention is: how to provide a systematic health data management solution that, while ensuring complete and irreversible isolation between user identity information and health data, also supports secure analysis and personalized services for health data.
[0008] [Technical Solution] The core of this invention lies in providing a technical solution that integrates and logically isolates informed consent forms and health data. This solution, through systematic design, completes the binding at the very beginning of the data lifecycle and enforces logical isolation and permission separation in subsequent processing, thereby fundamentally eliminating the risk of privacy leaks.
[0009] In a first aspect, the present invention provides a distributed, multi-dimensional health management data collection and intervention system, comprising: The personal data access terminal is used to simultaneously collect users' identity information and informed consent documents and multi-dimensional health data files, and to securely bind the two together; A data security processing center, communicatively connected to the personal data access terminal, comprises: The identity identification and anonymization module is used to create a unified original identifier for the bound identity informed consent document and health data file. Based on the content of the health data file, an anonymous health ID with no derivation relationship to the unified original identifier is generated through a first security algorithm. Access control module for implementing a hybrid access control policy based on roles and attributes, wherein the attributes include at least one of visitor attributes, environment attributes, resource attributes, and operation attributes; The identifier mapping library module is an independently encrypted database used to store the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path of the identity informed consent document; The health analysis and management engine communicates with the data security processing center to analyze and model anonymized health data and generate personalized health intervention plans. The system also includes: A privacy file library for storing encrypted informed consent documents related to the stated identities; A health analysis database is used to store anonymized health data associated with the anonymous health ID; The privacy file library and the health analysis database are configured to be physically or logically isolated; the health analysis and management engine is configured to only be able to access the health analysis database.
[0010] Optionally, the first security algorithm is a cryptographic hash function with a random salt added, and the cryptographic hash function includes SHA-256, SHA-3, or SM3 algorithms.
[0011] Optionally, access to the identifier mapping library module is limited to the system's core management process, which undergoes strict identity authentication; and the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path is atomically written to the identifier mapping library module through a database transaction mechanism after the identity informed consent document is encrypted and stored in the privacy file library and the health data file is anonymized and stored in the health analysis database.
[0012] Optionally, the access control module is configured to grant the health manager role access to the health analysis database based on the anonymous health ID, and to prohibit the health manager role from accessing the privacy file library and the identifier mapping library module.
[0013] Optionally, the access control module is further configured to: when access to the privacy file library is required, execute an authorization process that includes multi-level approval, user informed confirmation, and generation of a temporary token with time-limited validity and access scope restrictions; access behavior using the temporary token will be recorded in a separate audit log database.
[0014] Optionally, the health analysis and management engine includes: The feature processing unit is used to clean and extract features from the data in the health analysis database. The risk assessment unit is used to classify and assess the risk of anonymized health data using machine learning models. The intervention plan generation unit is used to combine the rule engine and recommendation algorithm to generate structured, personalized health intervention plans.
[0015] Secondly, this invention provides a method for health data collection and anonymization intervention, comprising the following steps: Step 1: Data Binding and Identification Steps Securely bind the user's identity-based informed consent document with its corresponding multi-dimensional health data file, and generate a unified original identifier for the bound data; Step 2, Dual Security Procedure: The identity-informed consent document is extracted from the bound data, encrypted, and stored in a privacy file library. Simultaneously, a first security algorithm is used to generate an anonymous health ID for the health data file that has no derivational relationship with the unified original identifier, and the anonymized health data is stored in a health analysis database. The privacy file library and the health analysis database are physically or logically isolated. The first security algorithm is a cryptographic hash function with an added random salt value, and the cryptographic hash function includes SHA-256, SHA-3, or SM3 algorithms. Step 3: Mapping relationship construction steps: In an independent encrypted identifier mapping library, the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path of the identity informed consent document in the privacy file library is stored. Step 4, Hierarchical Access Control Steps: By employing a hybrid access control strategy based on roles and attributes, the health manager role can only access anonymized health data in the health analysis database based on the anonymous health ID, but cannot access the privacy file library and the identifier mapping library. Step 5, Personalized Service Steps: Based on the anonymized health data associated with the anonymous health ID, a personalized health intervention plan is generated and delivered to the corresponding user through the anonymous health ID.
[0016] Optionally, in step 4, the hierarchical access control step further includes a special authorized access sub-step. When access to the privacy file library is required, the following steps are executed in sequence: the access administrator initiates a request and approval process, notifies the user and obtains temporary authorization, generates an access token with time and scope limitations, accesses the file based on the token, and records the complete audit log in a separate audit database.
[0017] Optionally, in step 5, delivering the plan to the corresponding user via the anonymous health ID specifically includes: storing the generated personalized health intervention plan in an independent plan database with the anonymous health ID as the primary key; when a user requests to obtain the plan, the encrypted identifier mapping library is securely queried based on the authenticated user identity to obtain the corresponding anonymous health ID, and then the plan is retrieved from the plan database and returned.
[0018] Optionally, in step 5, the step of generating a personalized health intervention plan specifically involves: performing feature engineering on anonymized health data, using a machine learning model to conduct health risk assessment, and integrating a rule engine and a recommendation algorithm to generate a plan that includes a health profile report, a list of actionable actions, and tracking targets.
[0019] [Beneficial Effects] The system of this invention integrates informed consent documents containing identity information with health data at the source, immediately performs physical or logical isolation storage, and introduces an independent encrypted identifier mapping library to maintain the controlled association between the two. This design ensures that even if a certain data storage area is accessed without authorization, attackers cannot match the user's identity with their complete health details, thus achieving true anonymity and solving the problem of privacy chain breakage caused by the exposure of ID numbers in existing technologies.
[0020] The system of this invention employs a hybrid access control strategy based on roles and attributes. Health managers are only granted access to the analysis database using an anonymous health ID. Their user interface and backend interface cannot access the privacy file library or mapping library. This allows professionals to conduct in-depth analysis, risk assessment, and generate personalized intervention plans from anonymized health data without knowing the user's identity, ensuring both service professionalism and strict privacy compliance requirements. When original informed consent documents must be accessed due to legal or regulatory needs, the system's built-in multi-level approval, user informed confirmation, temporary token generation, and complete auditing processes ensure that every special access is documented, traceable, and controllable. This mechanism can break the conventional anonymity when necessary, but through strict technical and procedural constraints, it minimizes the risk of privacy exposure.
[0021] The health analysis and management engine in this invention is based on anonymized datasets. Through a combination of feature engineering, machine learning models, and recommendation algorithms, it generates structured health profiles, actionable lists, and tracking goals. The solutions are precisely pushed to users via anonymous IDs. New data generated after user actions are anonymized again and integrated into the system, forming a continuously optimizing feedback loop. The entire process protects privacy while achieving personalized, dynamic, and intelligent health management.
[0022] In summary, this invention, through its integrated security design of binding as isolation, mapping as encryption, and access as control, not only systematically solves the long-standing pain point of identity and health data leakage in health management, but also provides a feasible technical path for safely and compliantly mining the value of health data, thus contributing to the construction of a trustworthy and efficient personal health management ecosystem. Attached Figure Description
[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0024] Figure 1 This is a schematic diagram of the overall architecture of the distributed multi-dimensional health management data collection and intervention system provided by the present invention.
[0025] Figure 2 This is the overall flowchart of the health data collection and anonymization intervention method provided by the present invention.
[0026] Figure 3 This is a detailed flowchart of the hybrid access control method based on roles and attributes provided by the present invention.
[0027] Figure 4 This is a schematic diagram of data flow provided by the present invention.
[0028] Figure 5 This is a flowchart of data anonymization encoding and access control provided by the present invention.
[0029] Figure 6 This is a schematic diagram of data flow and access isolation for health data processing and access control provided by the present invention. Detailed Implementation
[0030] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0031] Example 1 This embodiment provides a distributed, multi-dimensional health management data collection and intervention system, aiming to integrate personal health data from multiple sources while ensuring strict privacy protection and data value mining. For example... Figure 1 and Figure 6 As shown, the system mainly includes: a personal data access terminal, a data security processing center, a health analysis and management engine, a privacy file library, and a health analysis database. Among these, Figure 1 The static architecture of the system is shown. Figure 6 This further describes the data flow relationships between the components and the core access permission isolation design.
[0032] 1. Personal data access terminal Deployed on the individual user or data collector side, it is used to synchronously access and bind the user's "Health Management Informed Consent Form," "Health Questionnaire," and other multi-source health data through scanning, importing, and other methods. Multi-source health data includes, but is not limited to: monitoring data from IoT devices (such as smart bracelets, blood pressure monitors, etc.), electronic reports issued by medical institutions, and data actively entered by users through an app or web portal.
[0033] This access point has data format verification and preliminary cleaning functions, which is the first line of defense to ensure data quality, accuracy of anonymization mapping, and validity of subsequent analysis.
[0034] Data format validation includes, but is not limited to: (1) File basic verification: Check the type, size and integrity of the uploaded file.
[0035] (2) Data structure and template validation: For structured or semi-structured data, validate whether the data format conforms to the predefined specifications or patterns. For example, validate whether the JSON file contains the required fields, such as "measurement item", "value", "unit", etc., and whether the field value type (string, number, date) is correct.
[0036] (3) Logic and business rule pre-validation: Perform lightweight business rule checks at the client or gateway level. For example, check whether the "systolic blood pressure" value is within a physiologically reasonable range (40-250 mmHg) and whether the "date of birth" constitutes a reasonable age (greater than 0 years old and less than 150 years old). This step aims to intercept obviously invalid or malicious data and reduce the backend processing pressure.
[0037] Preliminary cleaning is performed after format validation passes, primarily targeting the parsed structured data content, including: (1) Missing value identification and standardization: Identify blank, NULL or "unknown" values in the data and standardize them according to the preset strategy of uniformly marking them as "NA" so that the subsequent analysis module can process them specially.
[0038] (2) Format standardization: unify the data representation format, convert various date formats ("2023 / 12 / 01", "01-Dec-2023", etc.) to the ISO 8601 standard format ("2023-12-01"); automatically split the blood pressure value "120 / 80" into two independent fields: "systolic pressure: 120" and "diastolic pressure: 80".
[0039] (3) Remove technical duplicates: Detect and remove duplicate records that are exactly the same in the same batch of uploads based on key fields (user ID, measurement timestamp, device ID).
[0040] (4) Handling obvious outliers: Use thresholds or simple statistical rules (such as a simplified version of the 3σ principle) to filter out extreme values that are physically or clinically impossible. For example, mark “2.5 meters” or “0.5 meters” in height data as outliers to be reviewed.
[0041] The necessity of these functions for subsequent processes is reflected in: (1) Ensure the accuracy and consistency of anonymization mapping: Accurate and clean data is the basis for generating unique and reliable anonymous health IDs. Incorrectly formatted or duplicated data may cause the same user to generate multiple inconsistent anonymous IDs, violating the "one person, one file" anonymization principle, or leading to data fragmentation.
[0042] (2) Improve the efficiency and accuracy of the health analysis and management engine: Low-quality data can seriously interfere with the training and prediction of machine learning models, leading to distorted risk assessments and ineffective intervention plans. Front-end cleaning can significantly reduce the processing burden and computational noise of the back-end analysis engine.
[0043] (3) Maintaining overall system security and stability: Format verification can effectively defend against injection attacks launched through malformed data. Preliminary cleaning can prevent system processing logic errors or storage anomalies caused by dirty data.
[0044] Therefore, data format verification and preliminary cleaning are essential technical steps in this distributed multi-source data integration system to ensure that the data is reliable from the source, the process is reliable, and the results are valid.
[0045] When logging into their personal data access point, users must use a time-based, one-time password two-factor authentication (2FA) mechanism to ensure account security and prevent unauthorized data uploads due to password leaks. The specific implementation is as follows: First factor (knowledge factor): The user enters the static password they set during registration.
[0046] The second factor (holding factor): A one-time dynamic verification code generated by the user on their bound trusted device. This embodiment preferably uses the time-based one-time password (TOTP) algorithm.
[0047] When a user registers for the first time or enables 2FA, the system generates a key and converts it into a QR code, which is then displayed to the user. The user scans this QR code using a mobile app (such as Google Authenticator or Microsoft Authenticator), and the key is stored in the app. Each subsequent login uses this key and the current timestamp to calculate a 6-digit dynamic code using the TOTP algorithm. This dynamic code is typically valid for 30 seconds. The user enters this dynamic code on the login screen to complete the second-factor authentication.
[0048] This two-factor authentication mechanism builds a security barrier from the source of data entry, ensuring that even if a user's static password is leaked, attackers cannot log in without control of the user's linked device. The entire authentication process is handled by a separate authentication service, and only the access token issued after successful authentication can be used for subsequent operations such as data upload.
[0049] The core objective of synchronously accessing and binding data is to ensure that documents such as the "Health Management Informed Consent Form" and the "Health Questionnaire" are logically confirmed as products of the same user and the same business activity, and to guarantee the integrity and non-repudiation of this association. This system adopts a "cryptographic hash-based metadata anchoring" scheme, rather than simple physical packaging. The specific implementation steps are as follows: (1) Client session binding and preprocessing During a user's upload session, each time a file is selected, the client immediately calculates the cryptographic hash value of that file locally. This hash value serves as the file's unique digital fingerprint.
[0050] The client assembles all metadata about the files to be uploaded—namely, filename, type, size, and calculated SHA-256 hash value—into a structured "pre-bound manifest" in JSON format. Then, it digitally signs this manifest using a valid access token from the current login session, generating a signature value. This signature ensures that the manifest was generated by an authenticated user during the current session and that its content has not been tampered with.
[0051] The client submits the signed "pre-bound manifest" along with all the original files as a multipart request to the server. The manifest is in the metadata section of the upload request, and the files are in the body.
[0052] (2) Server-side verification, storage and persistence binding The data security processing center's "File Receiving and Binding Service" receives the request. This service first verifies the validity of the access token attached to the request and then uses the token key to verify the digital signature of the "pre-bound manifest." If the signature verification passes, it proves the manifest's integrity and trustworthy origin.
[0053] The service streams each file to a temporary storage area. During or after storage, the service recalculates the SHA-256 hash value of each received file and compares it with the corresponding hash value provided by the client in the "pre-binding manifest". This step is crucial for tamper prevention, ensuring that files are not modified during network transmission or server processing. Only after all file hash values pass verification does the service proceed to the next step.
[0054] After the verification passes, the service performs atomic operations: a. Persistent storage of files: Permanently storing each file in its designated temporary or initial storage location.
[0055] b. Create the primary binding record: In the system's core relational database, create a new data packet binding record. This record must contain at least: a system-generated unique binding transaction ID, the uploading user ID, a timestamp, and most importantly, a field that points to a complete "pre-binding manifest" (containing all file hashes and storage paths).
[0056] c. Generate a Uniform Original Identifier: The system assigns a Uniform Original Identifier to the record bound to this data packet. From this point on, by binding the transaction ID and the Uniform Original Identifier, the informed consent form and the health data file are strongly associated at the system level.
[0057] The tamper-proof capability of this solution is guaranteed by the following three mechanisms: Pretransmission client hash: The digital fingerprint of data is fixed before it leaves the user's device.
[0058] Server-side hash verification after transmission: By comparing hash values, it is ensured that no bits of the file have been changed during transmission and reception.
[0059] Atomic binding based on database transactions: Hash verification, file storage, and binding record creation are executed as a single database transaction. Either all operations succeed or all operations are rolled back, avoiding intermediate states where the binding relationship and file status are inconsistent.
[0060] Therefore, "binding" essentially involves creating an authoritative metadata record in the system database that associates the cryptographic hashes and storage paths of all files, rather than physically packaging them. This approach ensures both the rigor and auditability of the association while maintaining the flexibility and efficiency of the storage system.
[0061] 2. Data Security Processing Center The data security processing center communicates with the personal data access point and is the core module of the system for achieving secure data isolation and processing. It internally includes at least: (1) Identity Identification and Anonymization Module: This module is used to create a unified original identifier (i.e., the main associated identifier, such as ZM-20241001) for each set of bound informed consent documents and health data files. In this embodiment, preferably, the unified original identifier can be a globally unique identifier (UUID) generated by combining a timestamp, device identifier, and random number. Subsequently, this module performs anonymization encoding, generating an anonymous health ID (such as Anon_9F3E7D) based on the health data file and through a first security algorithm. This anonymous health ID is designed to have no mathematical derivation relationship with the unified original identifier, making it impossible to reverse engineer.
[0062] In this embodiment, the preferred first security algorithm is a cryptographically secure hash function with a random salt added. The cryptographic hash function with the random salt can be implemented using various algorithms recognized as secure in the field, including internationally used algorithms such as SHA-256 and SHA-3, or the SM3 national cryptographic algorithm conforming to the standards of the State Cryptography Administration. The system can flexibly configure and select a specific hash algorithm according to the security compliance requirements of the deployment environment.
[0063] The system uses a cryptographically secure pseudo-random number generator to generate each salt value based on a true random entropy source, ensuring that its length and strength are sufficient. Employing a strategy of "one salt per user per batch" or "one salt per processing session," the system generates an independent and unique random salt value for each user's data processing session, effectively enhancing its collision resistance and anti-correlation analysis capabilities.
[0064] The generation, distribution, and lifecycle management of salt values are centrally handled by an independent and highly secure salt value management service, which is deeply integrated with an enterprise-level key management service to achieve hardware-level key protection. Each salt value is bound to a single data processing task and is marked as "consumed" after use, and cannot be reused or used for other purposes.
[0065] Salt values and the anonymous health IDs generated from them are stored separately and never in the same database or storage volume. All salt values are encrypted with KMS before storage. The ciphertext can be stored in a separate and strictly controlled "salt value library" or stored as a key attribute along with task metadata in an identifier mapping library, forming a dual security barrier composed of encrypted salt values and KMS key permissions.
[0066] Only in strictly authorized scenarios such as internal debugging or compliance audits, the system obtains the encrypted salt value and key ID by accessing the identifier mapping library, calls KMS to decrypt and obtain the plaintext salt value, recalculates the hash, and compares it with the anonymous health ID. This process is complex and subject to rigorous auditing to ensure that the salt value is not touched in daily business operations, thereby technically guaranteeing "no derivation relationship".
[0067] To further enhance the non-repudiable association between the original identifier and a specific user, the hash value of user-provided and verified information whose identity cannot be directly inferred can be incorporated as one of the generation factors during the original identifier generation process. For example, the salted hash value of the user's registered mobile phone number can be used in the identifier generation calculation.
[0068] The generation of anonymous health IDs follows a deterministic transformation process. Its core design principle is to strongly bind the ID to the health data content itself while completely decoupling it from the user's identity information. This process is performed as follows: a. Data Content Hashing: First, the system performs standardized serialization processing on the health data file already bound to the informed consent form and calculates its cryptographic hash value. This hash value, denoted as H_data, serves as a unique and compact digital digest of the health data.
[0069] b. Obtain a random salt value: The system requests a high-strength, cryptographically secure random salt value, Salt, from the Key Management Service (KMS), which integrates a hardware security module. This salt value is specifically generated for this anonymization calculation, following the "one data, one salt" principle.
[0070] c. Constructing Anonymous Input and Computation: The health data hash value H_data is concatenated with the random salt value Salt, or a cryptographically compliant mixing operation is performed to form the final anonymized input Input_anon. This Input_anon is then used as input and fed into a specified cryptographically secure hash function (SHA-256 in this embodiment) for computation. The output result is the anonymous health ID (Anon_ID).
[0071] The generation of Anon_ID relies on both the health data hash value H_data and the random salt value Salt. Due to the one-way nature and avalanche effect of hash functions, without knowing the specific salt value Salt, it is impossible to deduce the original health data content or its hash value H_data from Anon_ID, let alone associate it with the unified original identifier, thus achieving complete anonymity. After generation, the random salt value Salt is immediately encrypted by KMS and atomically stored together with the anonymous health ID Anon_ID and the unified original identifier in an encrypted identifier mapping library. This mapping library is the only place in the system that stores this complete association, and access is subject to the highest level of control.
[0072] This method ensures that identical health data content is generated, and under the premise of using the same salt value management strategy, the same Anon_ID will be generated. This provides a technical foundation for data deduplication, secure cross-institutional data comparison, and aggregation analysis, while never revealing individual identities.
[0073] This design establishes anonymous identifiers on the data ontology from the source, achieving stronger privacy protection than traditional pseudonymization, which is one of the core security innovations of this invention.
[0074] (2) Access Control Module: This module manages access permissions for data for different roles, including individual users, health managers, data collectors, system administrators, and system algorithm service accounts. Its core function is to implement differentiated and refined access control for informed consent documents and health data. This module implements a hybrid access control model based on roles (RBAC) and attributes (ABAC). All access requests must be approved by the policy decisions of this module (see [link to relevant documentation]). Figure 3 ).
[0075] In the hybrid access control model implemented by the access control module, attributes are key to achieving fine-grained, context-aware access control. Attributes include: Visitor attributes: the health management organization ID to which the operator belongs, their professional certification level (such as junior, intermediate or senior health manager), professional title, etc.
[0076] Environmental attributes: the specific time the access request was initiated, the source IP address, the security status of the device that initiated the request, etc.
[0077] Resource attributes: The data category (such as cardiovascular disease-specific management) corresponding to the anonymous health ID associated with the accessed health data, the data's preset sensitivity level labels (such as L1-L3), etc.
[0078] Operation attribute: The specific operation type of this access request, whether it is "read", "write", "batch export" or "single query".
[0079] The system's policy engine dynamically determines access based on the visitor's role and the aforementioned attributes. For example: "When the role is a health manager, their affiliated institution matches the list of institutions allowed access to the target data, and the access time is between 9:00 AM and 6:00 PM on weekdays, read operations on data with a sensitivity level ≤ L2 are permitted." All user and service access requests must undergo policy calculation and adjudication by this module.
[0080] (3) Identifier Mapping Library Module: This module is responsible for maintaining an independent, encrypted identifier mapping library. This library is used to securely store the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path of the informed consent form. This mapping relationship includes complex correspondences such as the encrypted path hash of the anonymous health ID and the informed consent form in object storage. Access to this library should be logged in detail and limited to a very small number of high-privilege, two-factor authenticated core system management processes. In this embodiment, the library is encrypted using a hardware security module (HSM) or an enterprise-level key management service (KMS).
[0081] The identifier mapping library module has the following technical characteristics in its implementation: Logical path storage: The encrypted storage path of the identity-based informed consent file stored in the library is not the physical path of the server's file system. In fact, after the file is encrypted and stored in the privacy file library, the storage service returns a globally unique logical access identifier, such as an object storage key or a Uniform Resource Identifier. This logical identifier is recorded in the mapping library, which enhances the abstraction of data storage and system portability, and avoids the security risks that may arise from the leakage of the physical path.
[0082] Atomicity Write Guarantee: To ensure absolute consistency of mapping data and integrity of system state, the write operation of the mapping record between the unified original identifier, anonymous health ID, and encrypted storage path is designed to be atomic. Specifically, the system adopts a database transaction mechanism to ensure that the complete mapping relationship is committed and persistently written to the identifier mapping library only after both branches of "dual security processing"—namely, the successful encryption and storage of the identity file in the privacy file library, and the successful anonymization and storage of health data in the health analysis database—have been confirmed. This mechanism effectively prevents incomplete mapping relationships or inconsistent data states caused by the failure of a single branch, improving the reliability of the entire system.
[0083] 3. Health Analysis and Management Engine The health analysis and management engine communicates with the data security processing center, but is configured to only access the health analysis database. This engine serves as the system's intelligent analysis center, and its functions are specifically divided into: (1) Feature Processing Unit: The feature processing unit is responsible for automatically preprocessing the collected anonymized health data to generate a high-quality feature set for subsequent modeling. Its processing flow covers three core stages: First, deep cleaning is performed, including handling missing and outlier values based on anonymized population statistics or model predictions, and performing logical consistency checks to identify contradictory data; then, normalization and standardization are performed, using methods such as Z-Score, maximum-minimum normalization, or robust standardization to eliminate the influence of dimensions based on the feature distribution. All parameters are calculated based on the anonymized training set and uniformly applied to the inference stage; finally, feature extraction and construction are performed, extracting statistical, periodic, and stability features from time-series data, promoting cross-modal fusion of structured, semi-structured, and unstructured data, and constructing clinically meaningful composite indicators based on medical knowledge. This unit ultimately outputs a standardized, information-rich anonymized user feature vector, directly supporting the analysis and modeling of the risk assessment unit.
[0084] (2) Risk Assessment Unit: This unit uses a machine learning model to quantitatively assess and classify health status based on preprocessed feature vectors. Its core value lies in integrating existing efficient algorithms into a strictly identity-isolated anonymous data environment for secure operation, rather than inventing entirely new algorithms.
[0085] This unit maintains a dynamically schedulable model library containing various models suitable for different tasks. For supervised learning tasks, such as identifying diabetes risk levels (low / medium / high) or predicting future blood glucose levels, gradient boosting decision tree models like LightGBM and XGBoost can be used, or random forests and logistic regression can be used as supplementary models. For unsupervised learning, such as using K-Means to segment anonymous users into healthy subgroups to discover potential patterns, deep learning models such as LSTM and CNN are introduced for feature extraction when dealing with complex data, such as time-series physiological signals or desensitized images.
[0086] The model training and deployment employ a strategy combining pre-training and online learning. During system initialization, the base model is first trained offline using historical anonymized data to achieve a cold start. Building upon this, to dynamically adapt to data changes, the system introduces an online learning mechanism, allowing newly generated anonymized data streams to update model parameters in small batches in a safe and controlled manner, or trigger periodic retraining. All processes are completed within an isolated anonymized environment.
[0087] The model's final output is a structured risk assessment package, including not only the primary risk score but also secondary risk indicators, confidence estimates, and key interpretability outputs. For example, the machine learning model interpretation visualization tool SHAP can clearly indicate that "elevated fasting blood glucose contributes +35% to the high-risk assessment of diabetes." Given the comprehensive requirements for processing efficiency, predictive performance, and interpretability, this embodiment preferably uses a gradient boosting decision tree model, represented by LightGBM, as its core.
[0088] (3) Intervention Program Generation Unit: Combining the rule engine and recommendation algorithm, a structured personalized health intervention program is generated. This personalized health intervention program includes at least: <1> Health profile and risk assessment report; <2> A specific, quantifiable, and time-bound list of actionable steps; <3> A goal setting and progress tracking module that includes gamification elements such as progress bars and achievement badges.
[0089] The rules engine is the core of translating medical expertise into executable, automated decisions. Its rules originate from a multi-source, authoritative, and traceable knowledge system, including: authoritative domestic and international medical guidelines and expert consensus, internal clinical pathways of collaborating medical institutions, dynamic risk prediction labels output by the risk assessment unit, and relevant laws, regulations, and ethical standards. This knowledge is transformed into structured, declarative rules, separated from business code for easier management. The specific storage and loading formats for rules include: rule files using the Drools rules language (.drl files), configuration files in JSON or YAML format, or configurable rule sets stored in database tables. Upon system startup or upon receiving an update notification, rules are loaded from these sources into the engine's knowledge base.
[0090] When a rule is executed, the intervention plan generation unit inserts the integrated, anonymized health profile as facts into the engine's working memory. The engine uses a pattern matcher to match the facts with the rule conditions, activates rules that meet the conditions, and resolves conflicts and prioritizes execution according to preset strategies. The executed rules generate specific intervention actions such as exercise suggestions, modify the factual state, and record the reasoning logic to generate explanatory instructions for the user. This process ensures the scientific rigor, compliance, and explainability of the intervention plan.
[0091] The recommendation algorithm employs a hybrid strategy to enhance the personalization and effectiveness of recommendations. The main strategies include: Content-based recommendation: Analyze the characteristics of historical health data associated with the current anonymous health ID (such as indicator change trends and questionnaire response patterns), and find pre-set intervention plan templates that match its medical logic for recommendation.
[0092] Collaborative filtering recommendation: At a completely anonymous level, the system periodically analyzes the relationship between the group's health profile and the feedback effects of various intervention programs (such as compliance rate and indicator improvement rate) through an offline machine learning pipeline (e.g., using matrix factorization models or LightGBM models). This allows the system to recommend more effective programs to user groups with similar health profiles. The updated model is then deployed as an online service.
[0093] Knowledge Graph Reasoning and Recommendation: As an enhancement, the system can construct a medical knowledge graph containing relationships between diseases, symptoms, drugs, nutrients, and guideline recommendations. Reasoning is performed on the graph based on anonymous user data to generate recommendations with deep medical evidence.
[0094] Ultimately, the set of basic intervention actions output by the rules engine will be merged, sorted, and weighted with action suggestions generated by the recommendation algorithm to form the final structured and personalized health intervention plan.
[0095] In this embodiment, the health analysis and management engine does not directly establish a connection with the health analysis database. Instead, the system sets up a dedicated data access service layer. This service layer provides a set of well-defined application programming interfaces (APIs), which the engine calls to request data. This data access service itself, as a trusted component of the system, is subject to authentication and authorization checks by the access control module, and is configured to only have permission to connect to the health analysis database. This design achieves access path convergence, limiting the potential attack surface to this single point—the data access service—facilitating centralized security auditing and hardening.
[0096] 4. Privacy File Library The privacy file library is a high-security storage area used to store identity-sensitive documents such as the "Health Management Informed Consent Form" encrypted with the AES-256 encryption algorithm.
[0097] 5. Health Analysis Database The health analytics database is used to store all anonymized health data associated with anonymous health IDs, such as physical examination indicators, device-collected data, and questionnaire responses.
[0098] In this embodiment, the system innovatively achieves strict isolation between the privacy file library and the health analysis database through a variety of technical means. Specific implementation methods include: ① Physical isolation (network isolation): Deploy the privacy file repository and health analysis database in different network security domains (such as different Virtual Private Clouds, VPCs), different server clusters, or even different data centers. Network communication between them is strictly restricted, such as through one-way gateways or by configuring firewall rules that only allow specific management services to access them, to achieve logical one-way or two-way blocking.
[0099] ② Logical isolation (access policy isolation): Implement completely independent permission policies at the access control layer of the two databases. Even if the underlying physical storage devices overlap, different user accounts, role permissions, row-level security policies, or mandatory access control mechanisms at the database level ensure that accounts from the health analysis and management engine can only access the schema or dataset of the health analysis database, and cannot obtain any credentials or permissions to access the privacy file library.
[0100] ③ Storage Entity Isolation: The two databases use completely independent storage entities. The privacy file database uses a dedicated object storage service instance or encrypted file system volume, while the health analytics database uses another independent database instance or cluster. They are separated in terms of storage media, management services, and data backup systems.
[0101] The above isolation methods can be used individually or in combination to build a defense-in-depth system, ensuring that even if a certain layer of defense is breached, attackers cannot associate with or simultaneously obtain identity and health data.
[0102] This design ensures that even if an attacker compromises one database, they cannot directly access information in the other database.
[0103] In this embodiment, the specific policy configuration of the access control module is key to achieving system security: (1) This module grants the health manager role permission to access the health analysis database based on an anonymous health ID. Its operation interface and API interface are strictly limited, preventing it from querying the privacy file library or the identifier mapping library, thereby ensuring that it can work in an environment where the user's identity is unknown.
[0104] (2) This module implements the principle of separation of duties for data collectors / administrators. For example, data collectors have the right to enter data, but the policy prohibits them from having access to the health analysis database at the same time; administrators are responsible for user management and system configuration, but cannot access specific health content.
[0105] (3) This module restricts the system algorithm service account to only read the anonymized health dataset and sets its network path and policy to prevent it from connecting to the privacy file library or mapping library.
[0106] (4) For special authorized access requirements, such as the need to access the original informed consent form due to legal or judicial compliance requirements, this module requires a strict authorization process: the request is initiated by an administrator with specific permissions and the reason is stated; the request must go through an approval chain that includes at least the legal compliance officer or a superior; the system notifies the user and obtains temporary authorization; after approval, the system generates a temporary access token with a time limit and strictly limited access scope; access behavior using this token is fully recorded in the audit log to achieve traceable and accountable minimal access (see Figure 5 ).
[0107] In the special authorized access process, the system notifies users and obtains their temporary authorization through multiple reliable channels to ensure that users have the ultimate right to know and control over access to their private files. Notification and confirmation mechanisms include: sending in-system push notifications to the user's linked app, sending SMS verification codes to the user's registered mobile phone number, or sending emails containing confirmation links to the user's registered email address. Users must complete the confirmation operation within a specified time, such as clicking "confirm," replying to the verification code, or clicking the link in the email, for authorization to be considered successful. If the user does not respond within the specified time, the system will automatically advance the process according to pre-configured policies, such as "defaulting to denying" the access request or "transferring it to a higher-authority approver for a final decision." This design balances the urgency of access needs with the protection of user rights.
[0108] All operations performed using temporary access tokens are automatically captured by the system and generate complete audit logs, which are stored in a separate audit database. This ensures that log data is separated from business data and is difficult to tamper with. Each audit log constitutes a traceable and verifiable chain of evidence, specifically containing the following information: Information on the subject of the action: Record all personnel accounts involved in this access, including the permission administrator who initially submitted the application, the approvers at each level in the approval chain, and the system account that ultimately performed the access operation.
[0109] Behavioral object information: Records the target object being accessed, i.e., the encrypted storage identifier of a specific informed consent document in the privacy file library, rather than plaintext identity information.
[0110] Time trajectory information: Accurately records key timestamps throughout the entire access lifecycle, including the application initiation time, the approval / rejection time of each level of approval, the generation and expiration time of temporary tokens, and the start and end times of the actual access operation.
[0111] Context and source information: a) A complete chain of approval opinions, recording the decisions and reasons of each approver.
[0112] b) The unique identifier of the generated temporary token and a description of its scope of permissions.
[0113] c) Information about the source of the access request, such as the IP address, device identifier, or hostname that initiated the request.
[0114] d) A summary of the legal or compliance reasons upon which this special visit is based.
[0115] System security information: a) Each log entry has a globally unique sequence number.
[0116] b) An integrity check value for the log content, which can be used to verify whether the log has been tampered with. Optionally, the system can synchronously write this hash value to a blockchain or read-only storage medium for permanent evidence preservation.
[0117] This audit log can not only be used for post-event verification, but also proactively empower security operations: Real-time alerts: Real-time alerts are triggered based on log analysis of abnormal patterns (such as access outside of working hours or high-frequency attempts).
[0118] Compliance Reports: Automatically generates periodic audit reports that comply with regulatory requirements.
[0119] Correlation analysis: Correlate with system logs from VPNs, bastion hosts, etc., to build a complete user behavior graph for in-depth security analysis.
[0120] The system employs multiple measures to ensure the integrity and authenticity of audit logs, including: Real-time writing: Logs are persisted to memory immediately after generation, reducing the time they remain in memory.
[0121] Integrity hash: Calculates a hash value for each log entry, which can be verified independently.
[0122] Enhanced evidence preservation: For high-security scenarios, the hash value of critical logs can be synchronously recorded to the blockchain or written once and read multiple times to achieve permanent and publicly verifiable evidence preservation.
[0123] In addition, the audit database storing audit logs is completely isolated from the business databases (privacy file library, health analysis database, and identifier mapping library) both physically and logically. Write permissions are granted only to the audit log service itself, while other accounts have only read-only permissions, which greatly limits the possibility of tampering.
[0124] Example 2 This embodiment provides a method for health data collection and anonymized intervention using the system described in Implementation 1. For example... Figure 2 As shown, the method mainly includes the following steps: Step 1: Data Binding and Identification Steps During the data entry phase, each user's "Health Management Informed Consent Form," along with their corresponding "Health Questionnaire" and other multimodal health data, are bound together into a complete data package. The data collection terminal or system assigns this data package a unified original ID, namely the primary association identifier (e.g., ZM-20241001).
[0125] Step 2, Dual Security Procedure: Figure 4 As shown, this step involves two key and parallel security actions: (1) Physical / Logical Isolation Storage: The Health Management Informed Consent Form containing personally identifiable information is extracted from the data packet, encrypted using the AES-256 encryption algorithm, and stored in a high-security privacy file library. This library is protected by physical network isolation or strict firewall policies.
[0126] (2) Anonymization encoding: A brand new anonymous health ID (e.g., Anon_9F3E7D) is assigned to the stripped health data portion. The generation process of this ID is unidirectionally independent of the main associated identifier and is generated through an independent hash function with a random salt value. After generation, the anonymized health data is stored in the health analysis database.
[0127] Step 3: Mapping relationship construction steps: The system securely stores the complex mapping relationship between the master associated identifier, the anonymous health ID, and the storage path of the private file in an independent encrypted identifier mapping library. This mapping library is completely independent of the health analysis database, both physically and logically, and access credentials are separated.
[0128] Step 4, Hierarchical Access Control Steps: The system achieves precise permission management for different roles through a hybrid access control model based on roles and attributes. (1) For the role of health manager, they can only access and analyze anonymized health data in the health analysis database through anonymous health ID, but cannot access the privacy file library and the identifier mapping library.
[0129] (2) For individual users, after logging in through their main account and two-factor authentication, the system queries their complete data mapping in the encrypted identifier mapping library based on their main associated identifier, thereby allowing the user to access their complete original data. The original data includes informed consent forms and health data.
[0130] (3) Strict access control and separation of duties strategies shall be implemented for data collectors / administrators and system algorithm service accounts.
[0131] (4) When it is necessary to break the anonymity status for special authorized access, it is necessary to execute a sub-process that includes multi-level approval, user informed confirmation, generation of temporary tokens with time and scope restrictions, and recording of complete audit logs.
[0132] Step 5, Personalized Service Steps: The health analytics and management engine generates personalized health intervention plans for each anonymous health ID based on anonymized health datasets. Specifically, this includes: feature engineering of the anonymized health data; health risk assessment using machine learning models; and integrating a rule engine with collaborative filtering or content-based recommendation algorithms to generate a plan that includes a health profile report, a list of actionable actions, and tracking goals. The generated plan is then accurately pushed to the corresponding user's personal data access point through the system's association with the anonymous health ID, forming a closed-loop service. Furthermore, any access to privacy files must be granted through the strict and specific authorization mechanism defined in step 4.
[0133] To ensure accurate delivery of solutions in a strictly anonymous environment, the system employs the following core mechanisms: (1) Solution storage: The generated personalized health intervention solution is stored in an independent solution database with the anonymous health ID as the primary key, ensuring the physical isolation between solution data and identity information.
[0134] (2) Secure Association Resolution: This is crucial for delivering the solution to the specific user via an anonymous health ID. The system performs secure association resolution through a trusted core service, strictly adhering to the principles of indirect association, front-end anonymity, and no data persistence. User-initiated retrieval (pull mode): When a user logs in through the client and requests to view a solution, their authenticated request reaches a trusted backend service. This service securely queries the encrypted identifier mapping library based on the verified user identity, resolves the uniquely corresponding anonymous health ID, and then uses this anonymous health ID to retrieve the corresponding solution from the solution database and returns it to the client for display. Throughout the entire process, the client and the solution database only interact with the anonymous health ID.
[0135] System-initiated notification (push mode): To improve the user experience, after a health plan is generated, the system can asynchronously trigger a high-security push service. This service securely queries an encrypted identifier mapping library based on the anonymous health ID associated with the plan, obtains the corresponding user's device push token and other notification identifiers, and then sends a notification message to the user's device containing no specific health content, such as "You have a new health plan to view." After the user clicks the notification, the aforementioned pull mode is triggered to complete the retrieval and display of the plan.
[0136] Through the above mechanism, the system ensures that health managers and algorithms work in a completely anonymous environment, while users can accurately and securely receive personalized services, forming a closed loop of privacy protection and effective intervention.
[0137] Example 3 This embodiment uses a typical health management scenario, with user Ms. Zhao, data collector Xiao Wang, and health manager Dr. Zhang as examples, to further illustrate the implementation process of the system and method of the present invention. All operations and processes involved are based on the aforementioned embodiment.
[0138] Phase 1: Data entry and security processing.
[0139] Data collector Xiao Wang logged into the system, created a file for Ms. Zhao, and simultaneously uploaded a scanned copy of her signed "Health Management Informed Consent Form" and "Health Questionnaire." The system performed a binding operation and generated a unified original identifier ZM-20241001. Subsequently, the system automatically performed dual security processing: the informed consent form was stripped, encrypted using AES-256, and stored in a privacy file library; at the same time, an unrelated anonymous health ID, Anon_9F3E7D, was generated for the health data and stored in the health analysis database. Finally, the system wrote the mapping relationship into the encrypted identifier mapping library: ZM-20241001 -> Anon_9F3E7D -> [encrypted storage path of informed consent form]. The system automatically notified Ms. Zhao that the file had been created.
[0140] Phase Two: Health Analysis and Intervention.
[0141] Dr. Zhang, a health management specialist, logs into his work platform. According to the system's access control policy, his interface only displays an anonymous health ID (Anon_9F3E7D) and basic health tags, such as "middle-aged woman" and "high blood pressure." These tags are summary descriptions automatically generated by the feature processing and risk assessment units within the health analysis and management engine after real-time analysis of the anonymous health data associated with Anon_9F3E7D. For example, the "high blood pressure" tag is added after the rule of systolic BP > 140 mmHg or diastolic BP > 90 mmHg is triggered. These tags provide the manager with information to quickly understand the case overview without revealing any direct identity information. After clicking on the ID, the system only allows him to access the data associated with that ID in the health analysis database. Dr. Zhang uses the tools of the health analysis engine for analysis or fine-tunes the system-generated draft plan to form a final "Personalized Health Intervention Plan," which includes specific goals, action lists, etc. He clicks "Send to User," and the system binds this plan to Anon_9F3E7D and pushes it to the user. Throughout the entire process, Dr. Zhang was unaware that Anon_9F3E7D corresponded to Ms. Zhao.
[0142] Phase 3: Service reception and feedback closed loop.
[0143] Ms. Zhao logs in via her personal app (two-factor authentication). The system verifies her identity with the backend user service using the security token carried in her login session. The user service, using this token, queries the identifier mapping database for her corresponding anonymous health ID (Anon_9F3E7D) on her behalf. The query result is used to retrieve a plan from the plan database and ultimately displayed on the app interface. The system securely retrieves her corresponding anonymous ID, Anon_9F3E7D, from the identifier mapping database using her login information, thus accurately displaying the plan on her app interface. Ms. Zhao executes the plan and provides feedback on the execution data through the app. This new data is synchronized to the health analysis database under the identity of Anon_9F3E7D. Dr. Zhang can see Anon_9F3E7D's compliance data on his workbench, such as "80% completion rate of this week's exercise goals" and indicator updates, and then adjust subsequent recommendations, forming a continuous optimization health promotion closed loop based on anonymous data.
[0144] This example clearly demonstrates how the present invention, through a systematic and integrated security design, achieves identity binding and isolation, mapping and encryption, and access and control throughout the entire data lifecycle. This fundamentally solves the privacy leakage risk when binding and managing informed consent forms and health data, while supporting effective personalized health management in an anonymous environment.
[0145] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A distributed, multi-dimensional health management data collection and intervention system, characterized in that, include: The personal data access terminal is used to simultaneously collect users' identity information and informed consent documents and multi-dimensional health data files, and to securely bind the two together; A data security processing center, communicatively connected to the personal data access terminal, comprises: The identity identification and anonymization module is used to create a unified original identifier for the bound identity informed consent document and health data file. Based on the content of the health data file, an anonymous health ID with no derivation relationship to the unified original identifier is generated through a first security algorithm. Access control module for implementing a hybrid access control policy based on roles and attributes, wherein the attributes include at least one of visitor attributes, environment attributes, resource attributes, and operation attributes; The identifier mapping library module is an independently encrypted database used to store the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path of the identity informed consent document; The health analysis and management engine communicates with the data security processing center and is used to analyze and model anonymized health data and generate personalized health intervention plans. The system also includes: A privacy file library for storing encrypted informed consent documents related to the stated identities; A health analysis database is used to store anonymized health data associated with the anonymous health ID; The privacy file library and the health analysis database are configured to be physically or logically isolated; the health analysis and management engine is configured to only be able to access the health analysis database.
2. The system according to claim 1, characterized in that, The first security algorithm is a cryptographic hash function with a random salt added, and the cryptographic hash function includes SHA-256, SHA-3 or SM3 algorithms.
3. The system according to claim 1, characterized in that, Access to the identifier mapping library module is limited to the system's core management process, which undergoes strict identity authentication. Furthermore, the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path is atomically written to the identifier mapping library module through a database transaction mechanism after the identity informed consent document is encrypted and stored in the privacy file library and the health data file is anonymized and stored in the health analysis database.
4. The system according to claim 1, characterized in that, The access control module is configured to grant the health manager role access to the health analysis database based on the anonymous health ID, and to prohibit the health manager role from accessing the privacy file library and the identifier mapping library module.
5. The system according to claim 1, characterized in that, The access control module is also configured to: when access to the privacy file library is required, execute an authorization process that includes multi-level approval, user informed confirmation, and generation of a temporary token with time-limited validity and access scope restrictions; access behavior using the temporary token will be recorded in a separate audit log database.
6. The system according to claim 1, characterized in that, The health analysis and management engine includes: The feature processing unit is used to clean and extract features from the data in the health analysis database. The risk assessment unit is used to classify and assess the risk of anonymized health data using machine learning models. The intervention plan generation unit is used to combine the rule engine and recommendation algorithm to generate structured, personalized health intervention plans.
7. A method for health data collection and anonymization intervention, characterized in that, Includes the following steps: Step 1: Data Binding and Identification Steps Securely bind the user's identity-based informed consent document with its corresponding multi-dimensional health data file, and generate a unified original identifier for the bound data; Step 2, Dual Security Procedure: The identity-informed consent document is extracted from the bound data, encrypted, and stored in a privacy file library. Simultaneously, a first security algorithm is used to generate an anonymous health ID for the health data file that has no derivational relationship with the unified original identifier, and the anonymized health data is stored in a health analysis database. The privacy file library and the health analysis database are physically or logically isolated. The first security algorithm is a cryptographic hash function with an added random salt value, and the cryptographic hash function includes SHA-256, SHA-3, or SM3 algorithms. Step 3: Mapping relationship construction steps: In an independent encrypted identifier mapping library, the mapping relationship between the unified original identifier, the anonymous health ID, and the encrypted storage path of the identity informed consent document in the privacy file library is stored. Step 4, Hierarchical Access Control Steps: By employing a hybrid access control strategy based on roles and attributes, the health manager role can only access anonymized health data in the health analysis database based on the anonymous health ID, but cannot access the privacy file library and the identifier mapping library. Step 5, Personalized Service Steps: Based on the anonymized health data associated with the anonymous health ID, a personalized health intervention plan is generated and delivered to the corresponding user through the anonymous health ID.
8. The method according to claim 7, characterized in that, In step 4, the hierarchical access control step also includes a special authorized access sub-step. When access to the privacy file library is required, the following steps are executed in sequence: the access administrator initiates a request and approval process, notifies the user and obtains temporary authorization, generates an access token with time and scope limitations, accesses the file based on the token, and records the complete audit log in a separate audit database.
9. The method according to claim 7, characterized in that, In step 5, delivering the plan to the corresponding user through the anonymous health ID specifically includes: storing the generated personalized health intervention plan in an independent plan database with the anonymous health ID as the primary key; when a user requests to obtain the plan, the encrypted identifier mapping library is securely queried based on the authenticated user identity to obtain the corresponding anonymous health ID, and then the plan is retrieved from the plan database and returned.
10. The method according to claim 7, characterized in that, In step 5, the step of generating a personalized health intervention plan specifically involves: performing feature engineering on anonymized health data, using a machine learning model to conduct health risk assessment, and integrating a rule engine and a recommendation algorithm to generate a plan that includes a health profile report, a list of actionable actions, and tracking goals.