Chronic disease follow-up data collection and storage method based on ai and blockchain

Abstract

The application provides an AI and blockchain-based chronic disease follow-up data collection and storage method, relates to the technical field of medical informatization, and acquires multi-source chronic disease data through a full-scene acquisition end, performs on-chain authentication and time synchronization through DID identification, constructs a multi-dimensional feature vector after standardization, inputs the multi-dimensional feature vector into a central decision AI model for risk assessment, outputs a score and follow-up intervention results, synchronously extracts a feature abstract, a model parameter abstract and a SHAP feature contribution degree vector through a model explanation module, generates a decision path code according to a cause-effect transmission sequence, assembles and constructs a verifiable decision evidence chain, constructs a Merkle tree through the hash of each evidence node, writes the root hash as a storage record into a blockchain, finally verifies external access through a dynamic authorization smart contract, realizes full-life-cycle controlled sharing and audit tracing, realizes AI decision endogenous interpretability, high dynamic edge variable point flow control and ciphertext domain compliance utilization, and balances account book lightness and privacy security.

Description

Technical Field

[0001] This invention relates to the field of medical information technology, specifically to a method for collecting and storing chronic disease follow-up data based on AI and blockchain. Background Technology

[0002] As the public health system evolves towards full-cycle health management, the follow-up management and data storage for chronic diseases such as hypertension and diabetes place higher demands on medical information platforms. In particular, in the dynamic environment of multi-terminal linkage between in-hospital clinical diagnosis, primary community follow-up, and patient home monitoring, how to ensure the real-time collection, secure storage, and compliant sharing of follow-up data across institutions has become a focus of attention in the healthcare industry. Currently, routine chronic disease management based on electronic medical record systems and medical evidence storage solutions based on basic blockchain technology have been initially applied, providing some digital support for chronic disease follow-up.

[0003] However, existing technologies for collecting and storing chronic disease follow-up data face the following technical challenges in meeting the aforementioned comprehensive requirements: 1. Medical AI decision-making lacks endogenous interpretability and causal evidence: Traditional intelligent chronic disease follow-up systems mostly rely on end-to-end "black box" reasoning. Their prediction results lack attribution explanation at the mathematical and clinical medical levels. At the same time, existing systems lack a mechanism to instantaneously extract and fix the model reasoning state and input scene during the forward propagation computation cycle, which makes it impossible to perform cryptographic causal reconstruction and security audit of the AI ​​decision-making process afterward, making it difficult to identify the medical responsibility subject. 2. The performance of uploading massive, high-frequency follow-up data to the blockchain conflicts with patient privacy and lacks an edge flow control feedback mechanism: Multi-source vital signs data in scenarios such as home and community have high concurrency and asynchronous time-series characteristics. Uploading the entire raw data or long waveform directly to the blockchain can easily lead to block expansion and a sharp drop in system throughput. Centralized storage, on the other hand, faces the risk of privacy leakage. In addition, existing technologies lack change point detection capabilities and reverse flow control mechanisms at the edge, and cannot adaptively adjust the collection and uploading frequency according to the trend of deterioration of vital signs, which can easily lead to sparse sampling and missed detection in sudden clinical crises. 3. Static desensitization techniques in cross-institutional business collaboration cannot balance data privacy and statistical value: Traditional platforms rely on centralized authorization, which cannot guarantee patients' dynamic ultimate control over their own data. When sharing research data, existing column-level desensitization or simple noise-adding methods are easily reconstructed from real individual medical records when faced with malicious cross-comparison using external auxiliary information. They cannot effectively prevent the reverse reconstruction of micro-level individual characteristics while protecting macro-level medical statistical characteristics.

[0004] To address the aforementioned issues, there is an urgent need for a method for collecting and storing chronic disease follow-up data based on AI and blockchain. This method would enable the cryptographic causal web-based solidification of decision-making facts throughout the entire lifecycle of chronic diseases, adaptive high-dynamic flow control of anomalies at the edge of home IoT, and fully homomorphic privacy computation and rigid auditing in cross-institutional research transfers. Ultimately, this would achieve a distributed, closed-loop defense for chronic diseases across all scenarios with high security, high interpretability, and high data throughput. Summary of the Invention

[0005] Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a method for collecting and storing chronic disease follow-up data based on AI and blockchain, which solves the problems mentioned in the background technology above.

[0006] Technical solution To achieve the above objectives, the present invention provides the following technical solution: a method for collecting and storing chronic disease follow-up data based on AI and blockchain, the method comprising the following steps: S1: Acquire multi-source chronic disease follow-up data through the full-scenario collection terminal, use the distributed identity identifier DID to perform on-chain identity authentication and time synchronization on the full-scenario collection terminal, and perform standardized processing on the authenticated data to generate corresponding multi-dimensional chronic disease feature vectors. S2: Input the multidimensional chronic disease feature vector into the central decision AI model for risk assessment, and output the patient's risk score and corresponding follow-up intervention results; S3: While generating the risk score, the decision-related information involved in this assessment is extracted synchronously through the model interpretation module. The decision-related information includes at least a feature vector summary, a model parameter summary, a feature contribution vector used to characterize the degree of contribution of each input feature to the risk score, and the risk score result. S4: Generate a decision path code based on the causal transmission order of the decision association information during the forward propagation process of the central decision AI model, and encapsulate the decision association information into a verifiable decision evidence chain according to the decision path code; S5: Perform cryptographic hash calculation on the verifiable decision evidence chain, and write the generated hash result into the blockchain ledger as a decision evidence record; S6: Based on the follow-up intervention results, control the corresponding follow-up execution terminal to collect incremental data, and verify the access rights of external institutions through the dynamic authorization smart contract deployed on the chain. Based on the decision storage record, complete the controlled sharing and audit traceability of the corresponding chronic disease follow-up data throughout its entire life cycle.

[0007] Preferably, step S1 specifically includes the following steps: S101: Distributed identity identifiers (DIDs) conforming to W3C standards are allocated and activated through a blockchain network for in-hospital chronic disease terminals, community-level terminals, home IoT device terminals, and scientific research terminals. S102: When each collection terminal uploads chronic disease follow-up data, it uses its corresponding private key to digitally sign the data packet. The blockchain verification node verifies the authenticity and non-repudiation of the data through the digital signature and DID. S103: Employ a streaming computing engine to perform time alignment, missing value compensation, and standardized coding on multi-source heterogeneous chronic disease follow-up data, and construct a multidimensional chronic disease feature vector for risk assessment.

[0008] Preferably, the central decision-making AI model in S2 includes a chronic disease risk stratification model. The specific process of outputting the patient's risk score and the corresponding follow-up intervention results is as follows: patients are divided into high-risk, medium-risk and low-risk levels according to the risk score, the corresponding follow-up frequency and intervention strategy are automatically matched according to different risk levels, and the large language model is called to automatically assemble and output personalized chronic disease intelligent education text as the follow-up intervention result based on the risk level.

[0009] Preferably, the specific process of writing the generated hash result into the blockchain ledger in S5 includes: performing hash calculations on each evidence node in the verifiable decision evidence chain, constructing a Merkle tree using the obtained hash values, and writing the generated Merkle root as a decision evidence record into the blockchain ledger to establish a unique mapping relationship between the corresponding risk score result and the original input features and model state.

[0010] Preferably, the process of constructing a verifiable decision evidence chain in S4 includes: encapsulating the feature vector summary, model parameter summary, feature contribution vector and risk score results into evidence nodes according to the calculation time sequence; generating decision path codes based on the causal mapping flow from input to output in the central decision AI model according to the evidence nodes; and constructing the corresponding verifiable decision evidence chain according to the decision path codes.

[0011] Preferably, the specific process of verifying access permissions through a dynamic authorization smart contract in S6 includes: the dynamic authorization smart contract includes an identity verification module, an authorization scope verification module, an authorization validity period verification module, and an audit record module. When a data access request is received, the dynamic authorization smart contract is invoked to automatically match the requester's DID, the range of the requested data items, and the current block timestamp. Only when the verification results of the above modules meet the preset conditions is a single valid on-chain data access authorization certificate generated.

[0012] Preferably, the method further includes a community chronic disease follow-up step: triggering the AI ​​voice follow-up system at the community level to perform automatic interactive follow-up based on the follow-up intervention results, using natural language understanding technology to convert the follow-up interactive voice into a structured follow-up ledger, establishing an association index between the structured follow-up ledger and the corresponding decision evidence record in S5, and packaging the association index and the follow-up doctor's electronic signature into the blockchain ledger to generate a record certificate for public health performance evaluation.

[0013] Preferably, the method further includes a home-based chronic disease monitoring and early warning step: using a home monitoring terminal to collect the patient's vital signs data in real time, and having an edge computing node calculate a trend deviation value based on the real-time vital signs data. When the trend deviation value exceeds a preset threshold, an abnormal event is generated, and the abnormal event is associated with the corresponding decision-making record. At the same time, an on-chain smart contract is triggered to dynamically increase the monitoring and on-chain frequency of the home monitoring terminal, and the encrypted abnormal segment of vital signs data is stored in the distributed file system IPFS. Only the storage path hash is recorded on the blockchain.

[0014] Preferably, the specific process of recording only the storage path hash on the blockchain is as follows: the encrypted abnormal segment vital signs data is divided into multiple data fragments and uploaded to the distributed file system IPFS, the hash value of each data fragment is calculated and a storage Merkle tree is constructed, and the root hash value of the storage Merkle tree is written into the blockchain transaction body as the storage path hash value to achieve lightweight storage of the blockchain ledger.

[0015] Preferably, the method further includes cross-institutional medical referral and research data utilization steps: When a patient is referred across hospitals, the referring hospital triggers an on-chain referral smart contract based on the referral request. After verifying the DID identity of the receiving hospital, the hospital packages the patient's on-chain data index, historical verifiable decision evidence chain, and referral purpose to generate an encrypted referral form and grants one-way authorization to the receiving hospital. When used for chronic disease research, the method receives data access requests from research institutions. After verifying the patient's authorization status through a dynamic authorization smart contract, a one-time access certificate is generated. A homomorphic desensitization AI model based on generative adversarial networks is called to desensitize the original chronic disease dataset. Differential privacy noise is introduced to remove the patient's individual identification features while retaining the overall statistical correlation of the dataset. The data access subject, access time, access scope, and access results are written into the blockchain ledger to form a full lifecycle audit record.

[0016] Beneficial effects This invention provides a method for collecting and storing chronic disease follow-up data based on AI and blockchain. It has the following beneficial effects: 1. This invention instantaneously captures snapshots of the input matrix and model parameters during the AI ​​forward propagation cycle through kernel bypass monitoring, and introduces a posterior SHAP attribution algorithm to calculate the mathematical contribution vector of physiological indicator features. At the same time, based on the chain-dependent hash concatenation formula, discrete facts are encapsulated into a verifiable chain of decision evidence. This enables the completion of on-site evidence preservation and endogenous interpretability determination of decision-making within the same clock cycle of risk score generation. It solves the problems of black box nature and lack of causal evidence in traditional AI chronic disease assessment, which leads to the inability to perform cryptographic causal reconstruction and the difficulty in identifying the medical liability subject afterward.

[0017] 2. This invention uses a lightweight edge change point detection algorithm to calculate the deviation value of vital signs on the home terminal. In critical situations, it uses on-chain device flow control smart contracts to reversely adjust the terminal's physical sampling and on-chain frequency. Combined with off-chain privacy slice symmetric encrypted storage and on-chain binary Merkle tree topology convergence algorithm, it achieves on-site capture of millisecond-level sudden clinical abnormalities and high-dynamic closed-loop flow control. While ensuring high system throughput and patient privacy, it solves the technical conflicts of block expansion and system paralysis caused by direct on-chain of massive high-frequency follow-up data, and the lack of feedback control mechanism on the existing edge side leading to sparse sampling and missed detection.

[0018] 3. This invention deploys Turing-complete dynamic authorization smart contracts at the consensus layer of a multi-center consortium blockchain to perform cross-institutional DID and multi-factor permission verification. Within an isolated sandbox, the original dataset is mapped to a fully homomorphic ciphertext space to run a minimax game optimization training of a generative adversarial network (GAN). Combined with the injection of Laplace differential privacy random noise into the boundary trusted front-end machine, this invention achieves dynamic supreme control of patients over their own public health assets and enables scientific research utilization of the ciphertext domain where data is available but not visible. This solves the problem of data silos and privacy leaks caused by traditional static desensitization techniques, which are susceptible to cross-comparison with external auxiliary information and malicious reverse reconstruction of patients' micro-level individual medical records. Attached Figure Description

[0019] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a flowchart of the multi-terminal scenario method of the present invention. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. 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. Specific Implementation Example 1: Please see Figure 1As shown, the AI- and blockchain-based method for collecting and storing chronic disease follow-up data forms a distributed grid closed loop in terms of spatial architecture. This loop has an in-hospital chronic disease center as the trust hub, grassroots communities and home IoT as the closed-loop execution terminals, and cross-institutional diagnosis and treatment and scientific research utilization as the asset value release terminals. The intelligent management of the in-hospital chronic disease center constitutes the decision-making foundation of this method. By running a central decision-making AI model and topological causal chain operator in the cloud, it completes the deep attribution assessment of chronic disease risk and the construction and on-chaining of a cryptographically verifiable evidence chain. Using this as a trust anchor, it radiates outward to control home terminals and community voice systems, thereby achieving a cross-temporal and spatial closed-loop defense against chronic diseases. Specifically, this is achieved by executing the following six core methodological steps: S1: Step 1: In the process of chronic disease management, if the identity of the data collection terminal cannot be effectively verified, problems such as falsifying devices to upload false follow-up data, tampering with chronic disease records, and falsifying public health follow-up ledgers may occur. Therefore, it is necessary to establish a unique and tamper-proof digital identity for the hospital chronic disease terminal, community grassroots terminal, home IoT device terminal, and scientific research utilization terminal at the data source.

[0022] Specific implementation process: When a specific all-scenario data acquisition terminal (such as a new type of smart home blood glucose meter) connects to the network for the first time, the security encryption chip built into the terminal generates a pair of asymmetric keys: public key... and private key Then, the terminal will send the public key. The device metadata (such as device serial number and manufacturer hash) is encapsulated into a registration request and sent to the smart contract. After verifying the validity of the metadata, the smart contract generates a corresponding distributed identity identifier string according to the W3C standard. At the same time, a corresponding DID document is constructed and stored, which publicly records the device's public key. The encryption algorithm type (such as the national cryptographic standard SM2 or Ed25519) and the authentication routing service are used. After registration, the DID serves as the unique and trusted identity identifier for the data collection terminal in the subsequent chronic disease follow-up data upload process.

[0023] The second step: Chronic disease management often faces extremely high medical liability risks. If the data is tampered with by hackers during the transmission process (for example, by tampering with the systolic blood pressure data of hypertensive patients), it will directly lead to the center's AI giving a fatally wrong medication intervention plan. Therefore, when uploading multi-source chronic disease follow-up data, the collection terminal must perform digital signature and use DID for real-time authentication to ensure the authenticity, integrity and non-repudiation of the data.

[0024] Specific implementation process: In this method, the collected multi-source chronic disease follow-up data exhibits a high degree of heterogeneity depending on the scenario: The hospital terminal collects patients' historical medical data (including structured clinical diagnoses, critical values ​​of laboratory tests, and electronic medical record texts). Community follow-up terminals collect medication adherence data and voice follow-up interaction text; The home monitoring terminal collects real-time vital signs data (such as pulse waves output per second and continuous dynamic blood glucose monitoring values) through high-frequency IoT sensors. For scientific research applications, the cleaned real-world research companion parameters are input.

[0025] When any acquisition device captures the above raw data packets At that time, the terminal first packages the data and adds a high-precision timestamp. Subsequently, the combination of data content and timestamps Perform a digest calculation (using the SHA-256 algorithm) to obtain the data hash value. SHA-256 Then use the private key For hash value Encrypt with private key and generate digital signature. Sign This ultimately forms a data message. The data is then sent to the receiving end. Upon receiving the data packet, the receiving end retrieves the corresponding public key based on the DID in the header. And perform signature verification: ; And independently calculate the hash value of the received data. SHA-256 If and only if This proves that the chronic disease data has not been tampered with by even a single bit during network transmission, and that it was indeed sent by the specific terminal represented by the DID, thus achieving non-repudiation verification.

[0026] Meanwhile, to prevent hackers from intercepting legitimate historical packets and launching replay attacks, the receiving side further compares the timestamps. Credible time relative to current consensus Perform a comparison, if (If the preset maximum network latency threshold is usually set to 3 seconds), then the data is determined to exceed the allowed time window and access is rejected.

[0027] The third step: The multi-source heterogeneous raw data that has been authenticated is often discrete, messy and mixed with a lot of noise. For example, home blood glucose meters may have large gaps in data due to patients forgetting to take the measurement; the data in the hospital HIS system is discrete static text; and community voice follow-up is sporadic, so time alignment processing needs to be performed first.

[0028] Specific implementation process: Using the patient's unique identification number (Patient_ID) as the key, the time limit is [not specified]. A sliding window (e.g., 24 hours) is used, and the multi-source data within the window is aligned according to a unified time scale. For data loss caused by missed patient testing, offline equipment, or network anomalies, a missing value compensation method based on a combination of Hidden Markov Model (HMM) and Expectation-Maximization (EM) algorithm is used. The true health status of patients with chronic diseases is abstracted as a hidden state chain. The collected discrete vital signs (such as blood glucose levels) constitute the observation sequence. When the time is detected Observations When missing data occurs, the parameters of the HMM model trained using historical follow-up big data are used. ,in The initial state probability distribution, The state transition probability matrix is... Given the observation probability matrix, the missing position is calculated using a forward-backward algorithm under a known observation sequence. The posterior probabilities of each hidden state Next, the expected value maximization algorithm (EM algorithm) is used to perform conditional expected value maximization iteration, and finally the missing values ​​are calculated. The core formula for calculating the optimal mathematical expectation estimate is as follows: ; : Indicates the derived time The compensation value for the absence of signs of chronic diseases; : Represents the total number of patients with latent health states (e.g., very high risk, stable, tendency to hypoglycemia, etc.) in the Hidden Markov Model. : Indicates that, given the known observational information of the entire sequence, the patient in Always in a state of hidden health The posterior probability; This indicates that the patient is in a state of latent health. Under statistical conditions, the mathematical expectation of this vital sign observation is calculated through multiple rounds of iteration to output a high-fidelity compensated data that conforms to both the patient's historical fluctuation trend and the pathological development pattern of chronic diseases, thus achieving smooth filling.

[0029] After completing time alignment and missing value compensation, different types of data undergo unified encoding processing: For unstructured discrete hierarchical data (such as medication adherence: full adherence, partial adherence, non-adherence), the one-heat encoding operator is used to convert it into sparse orthogonal basis vectors, eliminating artificially imposed weight bias; For continuous high-dimensional vital sign values ​​(such as systolic blood pressure, diastolic blood pressure, fasting blood glucose), in order to eliminate the influence of different physical dimensions on the subsequent gradient descent of the neural network, the Z-Score normalization operator is uniformly used for center scaling, and its core calculation formula is as follows: ; : Represents the dimensionless pure numerical value of the feature after standardization and coding; : Represents the original physical measurement values ​​of vital signs after missing value compensation; : Indicates the characteristic mean of the patient or the homogeneous group within the historical statistical period; This represents the historical standard deviation of the feature. After standardization, the discrete feature encoding results are concatenated with the continuous variable encoding results to form a fixed-dimensional multidimensional chronic disease feature vector. This feature vector, as the final output of S1, perfectly encapsulates a comprehensive, high-purity, and algorithm-ready health feature map of the patient during this period, covering in-hospital, home, and public health settings.

[0030] S2: After the multidimensional chronic disease feature vector generated by S1 is constructed, a risk assessment is performed on the multidimensional chronic disease feature vector, and corresponding follow-up intervention results are generated. Since the development of chronic diseases is affected by multiple factors such as changes in physiological indicators, medication adherence, long-term behavioral habits, and disease evolution trends, there are complex nonlinear coupling relationships between these factors. Traditional methods that rely on human experience to make judgments are difficult to accurately identify potential risks. Therefore, it is necessary to use a central decision AI model to perform deep representation learning and risk assessment on the multidimensional chronic disease feature vector.

[0031] Specific implementation process: S1 outputs a multidimensional chronic disease feature vector As input data, the data enters the central decision-making AI model, where it first undergoes non-linear feature extraction from the multidimensional chronic disease feature vector: ; in This is the weight matrix. For bias vectors, For activation function, This represents the extracted deep latent features. These features are then input into a risk assessment network to simultaneously predict multiple chronic disease risk dimensions. If the model simultaneously predicts K types of chronic disease risks, the risk score corresponding to the i-th risk dimension is calculated as follows: ; : indicates that in the output multidimensional chronic disease risk score vector, the th A quantitative probability value (between 0 and 1) of target organ damage or complications of a specific chronic disease. : Indicates the total number of chronic disease risk dimensions or complication types predicted by the model simultaneously; and : These represent the tasks in a multi-task network for the first task. The unique output layer weight matrix and bias terms for each chronic disease risk classification task ultimately yield a multidimensional chronic disease risk score vector: It is used to characterize the risk level of patients under different chronic disease dimensions.

[0032] Furthermore, due to limited medical resources, different management strategies are needed for patients with different risks. Therefore, patients are stratified by risk level based on a multidimensional chronic disease risk score vector.

[0033] Step 1: Classify patients by risk score (high, medium, low risk, etc.): Specific implementation process: First, the clinical expert team sets weight vectors for different chronic disease risk dimensions based on preset guidelines. Calculate the patient's overall risk index. Next, a dual-threshold hierarchical discrimination matrix model with soft-edge protection is introduced to set a low-risk control threshold. High-risk alarm threshold During operation, the operator uses conditional branching transfer functions to label the patient's risk level. The following determinations are made: ; in, This indicates the final severity rating label assigned to the patient for their chronic disease risk. : Represents the calculated overall risk index of the patient; These are fixed high-risk and low-risk thresholds, respectively. : Represents the term with the highest probability in the multidimensional risk scoring vector; : Indicates the threshold for intercepting a single critical value (e.g., a patient's overall score is not high, but their acute myocardial infarction progression score is extremely high, which triggers forced interception). If the following conditions are met... If the comprehensive index exceeds the standard, the judgment label is set to High, thereby achieving dynamic classification and stratification that takes into account both overall comprehensive consideration and does not overlook individual critical changes.

[0034] Step Two: After determining the risk level, it is transformed into an actionable clinical intervention outcome. High-risk patients require intensive follow-up and advanced medical intervention, while low-risk patients only need to maintain routine self-monitoring. By automatically matching the follow-up frequency and intervention strategy through algorithms, human error in missed diagnosis or scheduling can be effectively eliminated, achieving absolute standardization and automation of the entire life cycle management process for chronic diseases.

[0035] Specific implementation process: When the tag generated in the previous step... When the route is triggered: like Set the follow-up frequency of the follow-up execution terminal to "high-frequency monitoring" (e.g., collect vital signs every 2 hours at home IoT terminal, and conduct proactive interactive follow-up every 3 days by medical team), and upgrade the intervention strategy to "priority referral through green channel of tertiary hospital, dynamic adjustment of pharmacokinetics intervention plan, and real-time early warning push". like The follow-up frequency is set to "routine follow-up" (e.g., daily morning and evening data collection at home, and AI voice follow-up conducted by the community grassroots team every 2 weeks), and the intervention strategy is matched as "community public health doctor contracted intervention, control of diet and exercise behavior targets"; like The follow-up frequency is set to "self-managed low-frequency monitoring" (e.g., weekly data collection, quarterly routine follow-up), and the intervention strategy is set to "maintain existing lifestyle and keep health records unchanged".

[0036] The generated follow-up frequency information and intervention strategy information are packaged into an intervention program dataset.

[0037] Step 3: Traditional chronic disease education materials are often photocopied hard advertisements or rigid standard clauses, lacking specificity. For example, if a patient with both hypertension and diabetes is only shown separate dietary guidance, it will often cause conflict (such as some recommended foods for hypertension may be high in sugar). By using a large language model to dynamically assemble text based on the patient's unique risk vector and hierarchy, we can achieve "personalized" precision medical education, fundamentally improving patients' treatment adherence.

[0038] The specific implementation process is as follows: Keywords are extracted based on the patient's multidimensional chronic disease feature vector (e.g., stage II hypertension, accompanied by mild kidney damage, low medication adherence, and minimal exercise). A high-dimensional cosine similarity search is then performed in the medical knowledge base vector database to retrieve relevant, authoritative, and medically accurate underlying guideline entries. ; Next, patient characteristics and recall guidelines will be used. Current risk level The follow-up frequency and intervention strategy serve as contextual inputs in the large language model. The large language model utilizes its self-attention mechanism to perform cross-attention matrix inner product operations on each text authorization token within the computational layer. ; (Query): This is a query vector assembled from the patient's personalized chronic disease characteristics, current risk level, and intervention frequency. (Key) and (Value): This is the key vector and value vector obtained by linearly transforming the retrieved authoritative medical guidelines and historical high compliance texts. As a scaling factor, the model generates chronic disease education texts that match the patient's risk status based on attention weights. These texts, along with the aforementioned follow-up frequency and intervention strategies, are combined into a complete follow-up intervention result output, which serves as the final output of S2 and is then passed to S3 for decision-related information extraction and verifiable decision evidence chain construction.

[0039] S3: After completing the patient risk assessment and generating follow-up intervention results in S2, in order to ensure the traceability of decisions, the auditability of responsibilities, and the immutability of evidence in the subsequent chronic disease management process, it is necessary to simultaneously extract the key decision information involved in this risk assessment process and construct the corresponding decision-related information. Since artificial intelligence models usually involve a large number of parameter calculations and complex nonlinear reasoning processes in the chronic disease assessment process, if only the final risk score result is retained, it is impossible to restore the specific basis for the model to form the result. Therefore, it is necessary to simultaneously solidify the key data involved in the decision-making while generating the risk score in order to form a complete decision evidence basis.

[0040] Specific extraction process: After S2 outputs the risk score result, the system synchronously generates the corresponding decision-related information, which includes: Feature vector summary: refers to the sum of the input multidimensional chronic disease feature vectors. The fixed 256-bit string obtained after performing a one-way cryptographic hash (SHA-256) calculation represents the patient's original physical health snapshot at that time. Any subsequent tampering with the patient's blood pressure or blood sugar will cause the digest to not match, thus preventing data forgery. Model parameter summary: refers to the feature fingerprint extracted by hashing all static weight and bias matrix files of the central AI model currently performing inference. Because the chronic disease AI model will continuously learn and update online throughout its life cycle, locking the parameter summary can uniquely identify which specific AI model version was used to make the decision at that time, thus preventing the phenomenon of "making wrong decisions with the old version and using the new version to deal with audits". Risk scoring result: i.e., the probability vector output in S2 This represents the final clinical conclusion given by the AI. Feature contribution vector: is a vector that is related to the input feature vector. Continuous numerical vectors of the same dimension Each of the components The sign and absolute value of the value quantitatively characterize the pulling or inhibiting effect of this feature on the final risk score (e.g., ). The positive contribution rate of elevated glycated hemoglobin to high-risk rating is 35%.

[0041] To dynamically generate the aforementioned feature contribution vectors without sacrificing model accuracy. The SHAP additivity attribution algorithm, based on Shapley value theory, treats each follow-up evaluation prediction of the AI ​​model as a multi-player cooperative game, considering each dimension of the input features... All are participants in the game, in order to calculate a certain characteristic of chronic disease. Final risk score results The algorithm introduces a cooperative set to account for edge contributions. (This set is the complete feature set) Remove (any subset after), its feature contribution The core calculation formula is as follows: ; : indicates the derived first The absolute feature contribution of each input chronic disease feature to the current feedforward assessment score; : Represents the set of all features input to the chronic disease model. The total number of dimensions of the features; : indicates that the first [item] was removed from the entire set. A subset of random feature combinations constructed after considering 1 feature. This represents the number of features currently contained in this subset; : These are the marginal probability weight coefficients in combinatorics, used to perform unbiased amortization on feature combinations of various scales; and : These respectively indicate that the restricted features are only sets and only Under edge conditions, the conditional expectation prediction value output by the forward propagation of the neural network is used to calculate the high-precision contribution vector using the above formula. And output it.

[0042] By cascading the bypass dynamic audit and the kernel SHAP attribution algorithm, the system, at the same moment it outputs the chronic disease follow-up intervention plan, not only mathematically extracts the entire chain of causal evidence elements behind the AI ​​decision (including original input, model fingerprint, medical attribution, and final scoring results), but also packages them into a standardized decision-related information metadata structure. The decision-related information fully records the correspondence between input data, model status, attribution basis, and output results in this chronic disease risk assessment process, and serves as the input data for S4 to construct a verifiable decision evidence chain.

[0043] S4: After the previous step completes the synchronous extraction of decision-related information, the system enters the verifiable decision evidence chain construction stage. Although the feature vector summary, model parameter summary, feature contribution vector, and risk score results have been obtained in the previous step, these information are still independent data objects. Direct blockchain storage would not only cause data redundancy but also fail to prove the causal relationship between the data. For example, a third party might concatenate the input feature summary of one patient with the model parameter summary of another patient to create a falsified audit record. Therefore, it is necessary to generate decision path codes based on the causal transmission order during the AI ​​model's forward propagation process and construct a unified verifiable decision evidence chain for all decision-related information. This establishes an inseparable relationship between input data, model state, interpretation results, and the final decision. Decision path encoding: It is a series of cryptographic vectors containing topological direction guidance generated by the causal flow path encoding module. In essence, it is a digital mapping fingerprint of the AI ​​forward propagation computation graph. It clearly stipulates that the evidence nodes must satisfy the irreversible medical and computational causal timeline of "original input → weight parameters and normalization model → intermediate interpretability attribution → final decision score". Verifiable decision evidence chain: It is a nested cryptographic data structure in which all evidence nodes are strongly bound by a chain of hash pointers. Its core feature is that any small change in any preceding node will trigger an avalanche of failure in all subsequent nodes through the hash pointer.

[0044] The decision evidence index value is the hash value of the last node in the entire evidence chain or the Merkle root calculated from the chain. As an extremely short string, it uniquely represents the entire AI reasoning event containing hundreds of millions of parameters and multidimensional medical records.

[0045] When a medical institution, auditing court, or patient has doubts about a follow-up decision, a one-click chain-reverse audit of this verifiable chain of decision evidence can be performed. This involves retrieving the recorded decision evidence index value and performing a chain-reverse rehashing verification against the entire verifiable chain of decision evidence stored in an external database. A rigorous comparison is made across four dimensions to output the final audit result: verifying the authenticity of the input features. (Feature Summary): Verifies whether the current medical record summary is consistent with the one used when the decision was made, preventing fraudulent activities such as tampering with patient vital signs afterward to pass public health assessments; verifies the compliance of the AI ​​model. (Model Parameter Summary): Verify the model parameter summary of the inference execution to ensure that the officially filed version was being run, preventing unauthorized replacement of unapproved algorithm models; verify clinical attribution interpretability. (Feature Contribution): Verify the feature contribution vector to examine whether the pathological basis for the prescription or education plan given by the AI ​​is valid, preventing AI black box logic drift or nonsensical statements; verify the consistency of intervention conclusions (comparison). This function verifies the final risk score against the hash of the intelligent education text to prevent hackers from intercepting messages and maliciously tampering with the intervention results (such as changing a high-risk alarm to a low-risk, stable one). The verification result is presented as a binary absolute trust credential (True or False). If the hash value recalculated offline by the four nodes is completely consistent with the on-chain index value, it returns True and outputs a legally valid compliance audit report. If any part is tampered with, the verification is instantly interrupted and returns False, accurately locating which node and which piece of data was tampered with.

[0046] Step 1: Encapsulate 4 evidence nodes according to the computational sequence: The reasoning process of the AI ​​model is essentially a continuous computational pipeline, so the evidence needs to be encapsulated in the order in which the data is actually generated.

[0047] Specific implementation process: First, four independent structures are created, and the physical computation timing of AI forward propagation is strictly captured and atomically encapsulated: exist At any given moment, the initial input is captured, the multidimensional chronic disease feature vector is converted into a binary stream and hashed, and then bound to a global session identifier and a timestamp. Encapsulated as feature vector summary nodes ( ); exist At any given moment, when the neural network matrix weights are loaded into GPU memory, the feature fingerprint of the static weight matrix file is instantly captured, along with the algorithm version number and timestamp. Encapsulated as a model parameter summary node ( ); exist At the specified time, when the SHAP interpretation operator finishes running and outputs the marginal contribution of the features to the risk score, the high-dimensional feature contribution vector is serialized and timestamped. Encapsulated as feature contribution vector nodes ( ); exist At the point when the current propagation ends, the final probability is output, and the large model has assembled the follow-up text, the risk score is merged with the text hash and bound to a timestamp. Encapsulated as a risk scoring result node ( ); Each node contains a strict time-series self-numbering system, ready for topology mapping.

[0048] Step 2: Generate decision path encoding based on the causal mapping flow from input to output of the nodes: A purely physical time series (computational time series) is not equivalent to mathematical causal logic. To absolutely solidify "because of the characteristics of hypertension" at the mathematical level... ), in using this version of the hypertension AI model ( During the reasoning process, it was calculated that systolic blood pressure contributed 40%. This ultimately led to the high-risk intervention program ( "This clinical logic is the main thread, so it is necessary to use algorithms to generate decision path codes that can block the flow of information."

[0049] To accurately capture causal flows without compromising forward propagation performance, the system employs a topological causal path encoding algorithm that combines topological sorting of a directed acyclic graph (DAG) with a concatenated hashing mechanism. The algorithm abstracts the forward propagation of the AI ​​model during follow-up data evaluation as a DAG, where the data input operator, layer activation operator, SHAP interpretation operator, and Softmax output operator are vertices V, and the flow direction of the data matrix is ​​represented by directed edges E. During execution, the algorithm first arranges the causal dependencies of the computation graph in a linear order using topological sorting, and then sets a set of k encapsulated evidence nodes. The algorithm dynamically calculates the encoding and pointer of each causal chain using the following chained dependency hash concatenation formula: ; Among them, the initial state , : indicates the first The decision path code corresponding to each evidence node (which also serves as a hash pointer to the predecessor node). : Represents the net payload of evidence nodes encapsulated in the current layer, containing specific chronic disease follow-up features or model status; : Represents the path code of the previous level predecessor node. By forcibly introducing it into the hash calculation of the current layer, the technical effect of "firmly locking the historical causal relationship into this layer" is achieved. : Indicates the current topology level index (e.g., input layer is set to 1, parameter layer is set to 2, and so on), used to prevent the physical time sequence of nodes from being reversed; : This is a globally unique session identifier for this chronic disease follow-up assessment event, serving as the source of trust in the chain.

[0050] Specifically, iteration ,enter , with initial session ID The first-level path code is output via a SHA-256 circuit after concatenating bits with index 1. Iteration ,enter The operator forcibly With first-level coding Rehashed at index 2 to output the second-level path code. Iteration and The algorithm then proceeds in this manner, taking the explainable attribution nodes reflecting clinical attribution and the scoring result nodes reflecting intervention conclusions as the current inputs, layering them together. Each layer of encoding is used as an input factor for the subsequent hash. Finally, after the last iteration, the algorithm outputs a final path code containing the entire causal chain. This code serves as a globally unique index value for decision evidence.

[0051] Step 3: Construct the corresponding verifiable decision evidence chain according to the decision path code: After obtaining the decision path code, it is necessary to organize each evidence node into a unified data structure according to the established causal order.

[0052] Specific implementation process: Following the unidirectional topological order specified by the decision path coding, starting from the head node ( Starting with each node, the hash pointer of each node is pointed to its predecessor node in the computational causality, and the generated encoding is... The data is explicitly written into the header field of the corresponding node. Finally, the system serializes the four nodes, which contain pointers and codes, into a standard JSON-LD chained text object and uses the system's asymmetric private key to digitally sign the entire object. A complete and verifiable chain of decision evidence representing the AI-explainable decision-making process for this chronic disease follow-up is thus declared complete. Simultaneously, the system adds the tail feature values... The extracted value is output as the global decision evidence index value of the chain and sent to S5 for blockchain storage.

[0053] S5: After the verifiable decision evidence chain is constructed, the system enters the stage of generating decision evidence records and storing them on the blockchain. In S4, although a complete verifiable decision evidence chain has been formed, it still contains a large amount of decision-related information. If the entire evidence chain is directly stored in the blockchain ledger, it will not only significantly increase the storage burden on the blockchain, but may also expose patient privacy information. Therefore, it is necessary to perform hash compression processing on the verifiable decision evidence chain, and only write the decision evidence record that can uniquely represent the decision process into the blockchain ledger. This achieves a lightweight evidence storage mechanism in which the original evidence chain is stored off-chain and the decision evidence record is solidified on-chain. Blockchain ledger: In this method, it refers to a distributed, decentralized, one-way shared ledger based on cryptographic time-series block connections, jointly maintained and agreed upon by multiple parties. It does not rely on any centralized server and ensures that every record written into it has the characteristics of being permanently immutable and linearly irreversible in time through cryptographic hash chains and consensus algorithms. Decision-making records are used to uniquely represent a complete AI follow-up decision-making process; Merkle root is used to uniquely map the complete state of the entire verifiable chain of decision-making evidence. By writing decision-making records into the blockchain ledger, a permanent association between the original input data, model state, and risk scoring results can be established, providing a basis for subsequent accountability and credible auditing.

[0054] Step 1: Perform hash calculations on each evidence node in the verifiable decision evidence chain: In order to achieve offline and accurate auditing of the four independent dimensions of "input, parameters, attribution, and conclusion" in the entire AI reasoning process, the composite facts in the evidence chain are deconstructed so that each evidence node has its own independent cryptographic fingerprint that can be indexed separately.

[0055] Specific implementation process: The verifiable decision evidence chain generated by S4 is split into four basic evidence nodes encapsulated in the previous step: feature vector summary node ( ), Model Parameter Summary Node ( ), feature contribution vector node ( ) and risk scoring result nodes ( Subsequently, hash calculations are performed on each of the four heterogeneous structures, mapping them to fixed 256-bit leaf node hash values. The calculation logic is as follows: ; ; These four hash values, serving as the underlying cryptographic foundation, completely conceal the patient's physical and physiological data, preparing to be input into the subsequent binary tree operator.

[0056] Step 2: Constructing a Merkle tree using each hash value: In order to establish the overall relationship between each evidence node and further compress the amount of evidence data, it is necessary to construct a Merkle tree based on the leaf hash values.

[0057] Specific implementation process: The output from the previous step... As the leaf layer (leaf nodes) of the tree, the algorithm initiates the cascading two hash binary trees merging algorithm. First, in the first iteration, adjacent leaf nodes are forcibly concatenated bit by bit and a second hash is performed to generate intermediate wiring layer nodes (branch nodes). and : ; ; Next, the algorithm enters the second iteration, which involves the intermediate branch nodes. and Then, horizontal concatenation hashing is performed again to converge and generate the vertices of the entire tree, namely the Merkle Root. The core calculation formula is as follows: ; The obtained MerkleRoot can uniquely represent the entire verifiable decision evidence chain. When any evidence node changes, its corresponding leaf hash value will change, which will further cause the MerkleRoot to change, thereby realizing the detection of the integrity of the entire evidence chain.

[0058] Step 3: Write Merkelgen into the blockchain ledger and establish a unique three-in-one mapping relationship: Only by writing Merkelgen into the immutable blockchain ledger through network consensus can the decentralized authority of the blockchain be used to establish a three-in-one physical and legal mapping binding between the "scoring conclusion", "original physical characteristics" and "model state version", thus eliminating any possibility of subsequent forgery or shirking of responsibility.

[0059] Specific implementation process: The MerkleRoot output from the previous step is encapsulated as the core notarization field into blockchain transaction data: ; The transaction is broadcast to the blockchain network, and validating nodes invoke the PBFT algorithm to perform a three-phase consensus vote consisting of pre-preparation, preparation, and submission. When more than [number missing] [nodes] pass the vote... After the compliant nodes confirm that everything is correct, the transaction is officially packaged into the latest block height, generating a consistent blockchain hash and on-chain block timestamp across the entire network. Because the Merkle tree algorithm has extremely high mathematical resistance to collisions, as long as the original input feature vector ( ), model parameter weights ( ) or the final risk score result ( If even a single bit in the chain is modified, the derived leaf hash and the top-level MerkleRoot will be completely changed according to the avalanche effect, thus becoming completely out of sync with the hash value recorded in the on-chain consensus.

[0060] By writing MerkleRoot into the blockchain ledger, a physical rigid closed loop is created on the chain for the current follow-up decision. The blockchain ledger records at least the following: decision evidence record; block height; block timestamp; transaction identifier. Once the blockchain is confirmed, the decision evidence record corresponding to this chronic disease follow-up decision is permanently fixed in the blockchain ledger.

[0061] S6: Once the decision-making evidence record generated by AI inference is solidified on the blockchain, the system enters the closed-loop control, controlled sharing, and audit traceability stage for chronic disease follow-up data. Chronic disease management is a long-term, dynamic evolution process. The risk assessment results and follow-up intervention results output by the AI ​​model are not the end point of the business process, but rather the control basis for subsequent data collection, intervention execution, and data flow. If subsequent collection behavior cannot be dynamically adjusted according to the patient's risk status, problems such as insufficient monitoring of high-risk patients and excessive collection of data from low-risk patients may easily occur. At the same time, chronic disease data has high data sharing value in the process of referral, medical alliance collaboration, and scientific research. If a trusted authorization mechanism is lacking, problems such as unauthorized access, privacy leaks, and inability to trace the responsible party may easily occur. Therefore, this method uses the decision-making evidence record generated in S5 as a trusted anchor point, controls the corresponding follow-up execution end to collect incremental data based on the follow-up intervention results, and uses dynamic authorization smart contracts to automatically verify the access rights of external institutions, realizing trusted management of chronic disease data throughout its entire lifecycle from collection, analysis, sharing to auditing. Dynamic authorization smart contracts refer to decentralized access control programs that are pre-deployed in the blockchain ledger and executed by the blockchain consensus network. They do not rely on any manual approval and operate entirely based on cryptographic rules and pre-set code logic. The contract encapsulates four major functional code logics: identity verification, scope definition, time limit determination, and non-repudiation audit. It can upgrade the traditional "pre-existing static authorization" to "in-process dynamic on-demand authorization" that changes in real time according to the follow-up status.

[0062] The decision record is the Merkle Root and its associated on-chain records written into the blockchain ledger in S5, used to uniquely identify a complete chronic disease risk assessment and intervention decision-making process.

[0063] Step 1: Dynamic Authorization Smart Contract Multi-Module Structure Division and Access Request Reception: In order to achieve multi-dimensional and three-dimensional defense against complex external requests, a modular and decoupled architecture needs to be adopted within the smart contract. The four core boundaries of medical data security—identity, scope, time, and auditing—are independently guarded by different dedicated code modules, thereby ensuring the efficiency and rigor of the verification process.

[0064] Specific implementation process: A clear four-layer defense architecture was built for dynamically authorized smart contracts: The identity verification module is specifically responsible for verifying whether the physical entity initiating the request truly exists and possesses legitimate digital access qualifications. Authorization scope verification module: responsible for limiting the data dimensions that the requester can read, preventing unauthorized access to privacy; Authorization validity verification module: responsible for controlling the clock boundary of access from the blockchain timeline dimension; Audit logging module: responsible for recording all parameters of the entire verification process on the blockchain.

[0065] When an external organization sends a call transaction to the public interface of the contract through a trusted gateway, the system formally captures the data access request and transforms it into a structured parameter stream, which is then input to the four modules mentioned above.

[0066] Step Two: Execution of Multi-Factor Composite Logic Verification Algorithm and Automatic Parameter Matching: Access decisions for medical follow-up data must be absolutely real-time and objective. By automatically matching multi-dimensional security factors at the consensus layer through algorithms, the possibility of human intervention or collusion by centralized administrators can be eliminated, and the rigor of mathematics ensures the absolute compliance of access control.

[0067] Specific implementation process: Upon receiving a request, the smart contract immediately initiates a multi-factor composite logic verification algorithm that verifies identity, scope, and timeliness. Let the parameter packet input by the external request initiator be... The algorithm first extracts the timestamp of the current block generated by the blockchain consensus network through the identity verification module. And retrieve the privacy authorization control matrix preset by the patient for the requester from the on-chain state database. The algorithm takes the above dynamic parameters as input variables and feeds them into the composite check function. The core formula for the function's judgment is as follows: ; : Indicates the final Boolean result of the multi-factor composite logic verification algorithm (can only be True or False); This indicates that the authentication module calls the requester's public key to verify the digital signature of the request, in order to ensure the unforgeability of the request subject; : This indicates that the authorization scope verification module compares the scope of the requested data items with the allowed privacy mask in the authorization matrix, and must be true; This indicates that the authorization validity verification module determines that the current block timestamp must be less than or equal to the authorization expiration timestamp specified in the matrix; : Represents the logical AND operator in cryptography. The smart contract allows the access process to proceed if and only if the results of the three logical branches are all true. Otherwise, the access request is rejected. The above mechanism ensures that the access subject, access scope and access time limit all meet the authorization requirements.

[0068] Step 3: Generation and auditing of a single valid on-chain data access authorization credential: After the permission verification is passed, the dynamic authorization smart contract generates a single valid data access authorization credential based on the current block status.

[0069] The specific implementation process is as follows: After the composite verification algorithm outputs a pass signal, the smart contract obtains: the hash value of the current block, the requester's DID, the patient's encrypted index, and the current authorization information. On-chain, it dynamically assembles these into a fixed-length hexadecimal string using a cryptographic hash operator, which serves as a single-use, valid on-chain data access authorization credential. This credential is forcibly injected with a single-use, single-execution state lock by the smart contract. The contract asynchronously pushes this credential to an external trusted gateway and simultaneously calls the audit logging module to record the identity of the accessing entity, the scope of the request, the timestamp of the consumption, and the generated credential hash value. The package is persistently written onto the blockchain as a new audit block transaction, completing the entire process of record-keeping. After the trusted gateway across institutions intercepts the on-chain authorization certificate, the certificate will automatically trigger a one-time handshake with the decryption circuit in the gateway, opening only a one-way read stream of a small segment of incremental follow-up data specified by the certificate. Once the external institution has finished extracting the data, the certificate execution state lock in the gateway will automatically flip to the invalid state on the blockchain, making the certificate instantly become invalid. In this way, while ensuring the efficiency of cross-institutional collaboration, a closed-loop controlled flow mechanism for the irreversible and non-leaking of chronic disease privacy data is built based on blockchain smart contracts.

[0070] Please see Figure 2 As shown, based on the follow-up intervention results generated by S2 and the closed-loop control instructions formed by S6, the system further triggers the community chronic disease follow-up process, realizing automated follow-up management and performance tracking in grassroots community scenarios: Community-based chronic disease follow-up steps: Community-based chronic disease follow-up based on multimodal interaction and performance contract: Step 1: Trigger the community-based AI voice follow-up system to perform automated interactive follow-up based on the follow-up intervention results: The follow-up intervention results output by S2 and S6 determine the risk level of patients. For low- and medium-risk patients, routine follow-up needs to be maintained at the community level; for high-risk patients, frequent and proactive follow-up is required. If community doctors are to make phone calls one by one, it is not only time-consuming and labor-intensive, but also often leads to untimely follow-up for high-risk patients due to subjective forgetfulness. By using an algorithm-controlled AI outbound calling system to automatically match educational texts and execute multi-round dialogues, the follow-up actions can be made more immediate, standardized, and cost-effective.

[0071] The specific implementation process is as follows: The community chronic disease system monitors the intervention strategies issued by S6 in real time. Once it captures a follow-up scheduling instruction containing a specific patient (Patient_ID), the system immediately extracts the bound personalized chronic disease intelligent education text as the initial input for the dialogue state machine. The voice gateway automatically initiates an outbound call to the patient's registered phone number. When the patient answers, the AI ​​voice follow-up system drives the text-to-speech (TTS) engine to generate human-like interactive audio based on the medical theme in the education text (e.g., informing patients with stage III hypertension that they must reduce their high-salt diet and checking for missed medication). This enables highly realistic two-way multi-turn spoken follow-up interaction with the patient, achieving automated follow-up coverage for community chronic disease patients through the above methods.

[0072] Step 2: Use Natural Language Understanding (NLU) technology to convert interactive voice into structured follow-up records: The voice feedback generated by patients during follow-up is usually highly colloquial and difficult to use directly for medical data analysis. Therefore, it is necessary to convert interactive voice into structured follow-up records.

[0073] The specific implementation process is as follows: First, the system converts the patient's follow-up audio stream into raw text strings in real time. Then, it uses a medical natural language understanding model to perform entity recognition and semantic parsing on the text content, identifying drug names, symptom descriptions, physiological indicators, and behavioral compliance information. The recognition results are then filled into a standardized follow-up record template. A medical named entity recognition method based on a combination of bidirectional long short-term memory networks and conditional random fields is adopted, and its scoring function is as follows: ; : Represents a given sequence of input medical text In the target annotation path The overall probability score is as follows; : Represents the state transition probability matrix of the CRF layer, where Explicitly representing from medical entity labels (e.g., "symptom prefix") shifted to labels The probability of numerical transition (e.g., "symptom content"); : represents the feature emission probability matrix output by the bidirectional LSTM network, where The text token representing the i-th position is predicted to be a medical tag. The system uses the Viterbi algorithm to search for the entity annotation path with the highest probability to identify medical entity information in the text, based on the confidence level of (e.g., "blood pressure value").

[0074] For example, "I took my blood pressure medication this morning and my blood pressure was 145 / 92" can be automatically converted to: Medication status: Medicated; Drug type: Antihypertensive drug; Systolic blood pressure: 145 mmHg; Diastolic blood pressure: 92 mmHg, ultimately generating a standardized structured follow-up record.

[0075] Step 3: Establish a correlation index between the structured follow-up ledger and the decision evidence record in Step 5: In order to ensure that the community follow-up behavior can be traced back to the corresponding AI decision basis, it is necessary to establish a correlation between the current follow-up record and the decision evidence record formed in S5.

[0076] The specific implementation process is as follows: The system creates a composite index table in the local database, retrieves the unique global serial number (Record_ID) of the newly generated structured follow-up ledger, and simultaneously, the system reverse-engineers the business flow to retrieve the specific Merkle Root string that triggered this patient's follow-up visit and solidified it on the blockchain in S5. The system then calls an encrypted mapping function in the background to cross-bind [Record_ID] and [Merkle Root] with a foreign key, generating a globally unique associated index string. ; This association index enables a closed-loop causal chain between AI risk assessment results, follow-up task generation, and community follow-up execution.

[0077] Step 4: Introduce electronic signatures for follow-up doctors and generate performance record vouchers: After generating the structured follow-up ledger, the system will provide: a summary of the structured follow-up ledger; a summary of the follow-up voice recording; and a related index. The data is jointly packaged into a performance evaluation data package, which is then confirmed and electronically signed by the corresponding follow-up doctor.

[0078] The specific implementation process is as follows: After confirming the physiological indicators in the ledger, the doctor inserts their dedicated medical digital certificate private key (issued uniformly by the National Health Commission CA Center or the blockchain DID) into the terminal and performs a high-strength asymmetric digital signature on the entire performance evaluation data packet. The system then assembles the electronic signature, associated index, and ledger summary into a legitimate public health assessment transaction and submits it to the blockchain consensus network. The "Public Health Performance Evaluation Contract" deployed on the chain is activated. After the contract passes the compliance verification of the doctor's signature and associated index, it automatically calls the underlying blockchain consensus to record the transaction in the latest blockchain ledger. After successful writing, a corresponding public health performance evaluation record is formed. Since this record is simultaneously associated with: AI decision-making evidence storage record; actual follow-up execution record; and doctor's responsible signature, it can realize credible traceability and performance verification of the entire process of community chronic disease follow-up, providing objective and credible data basis for subsequent public health performance evaluation.

[0079] Furthermore, chronic disease management will be extended to patients' home settings. By continuously collecting patients' vital signs data through home monitoring terminals, and combining edge computing, blockchain evidence storage, and distributed storage technologies, real-time early warning, dynamic data collection and control, and reliable auditing of abnormal chronic disease states can be achieved.

[0080] Step 1: Collect vital sign data using a home monitoring terminal and calculate the trend deviation value: The home monitoring terminal worn by the patient uses a high-frequency sensor to collect multidimensional vital signs data streams in a continuous time series format. (These represent the current blood pressure, blood sugar, and heart rate values, respectively). The home monitoring terminal or edge gateway constructs a sliding time window from the continuously collected vital sign data and extracts the statistical feature vector within the current window. To measure the degree of deviation between the current physiological state and the historical steady state, the trend deviation value is calculated: ; : Represents the calculated dynamic trend deviation of the current home vital signs sequence (a dimensionless scalar distance); : Represents the feature vector of the vital sign waveform within the current sliding window; : This indicates that the system internally stores the baseline vector of the patient's average vital signs during the aforementioned stable historical period; : Represents the inverse covariance matrix of the historical stable period vital signs data dimension, used to forcibly eliminate the inherent coupling collinear noise between multidimensional features such as blood pressure and heart rate in space. Through the above calculation, the correlation influence between multidimensional vital signs is eliminated, and real-time monitoring of pathological change trends is achieved.

[0081] Step 2: Generate anomaly events and establish a connection with S5's decision evidence records: When detected ,in When the preset abnormal threshold is not met, the system determines that the patient's vital signs have changed abnormally, and instantly interrupts the current normal loop, at which point an abnormal event message is generated: ; in: Used as an identifier for abnormal events; The time when the anomaly occurred; This is an abnormal indicator type; To address the deviation, the Merkel root record corresponding to the patient's latest decision-making record in S5 was then retrieved. And construct an index for association of abnormal events: ; This association index is used to establish a correspondence between current abnormal home events and historical AI risk assessment results, enabling reliable tracing of the disease's evolution.

[0082] Step 3: Trigger the on-chain smart contract to dynamically increase the monitoring and on-chain frequency: When an abnormal event occurs, the system automatically adjusts the data collection and upload frequency of the home monitoring terminal according to the level of abnormality. If the level of abnormality reaches a preset threshold, the device's operating parameters are switched from the normal monitoring mode to the enhanced monitoring mode. For example, the data collection frequency is adjusted from... Upgraded to The data upload interval is determined by shortened to ,in: , By dynamically adjusting the monitoring strategy, more intensive vital sign data can be obtained during abnormal stages, providing a complete basis for subsequent clinical analysis.

[0083] In order to meet the dual technical requirements of secure storage of massive medical waveforms and minimalist and lightweight blockchain ledger, the system immediately proceeded to the final step, launching the IPFS distributed slicing and storage Merkle tree convergence algorithm.

[0084] Step 1: Local Symmetric Encryption of High Dynamic Data and Multi-Shard Upload to IPFS: Once the enhanced monitoring mode is activated, the system acquires high-frequency vital sign data files generated during the abnormal time period: First, the data file is encrypted using a symmetric encryption algorithm: ,in: This is the dynamic key corresponding to this abnormal event; The encrypted vital signs data file is then divided into multiple data fragments of fixed length: ; The edge gateway, acting as a client node of IPFS, utilizes a peer-to-peer (P2P) distributed network routing algorithm to route this... Each fragment is uploaded and distributed to a nearby distributed IPFS node cluster jointly maintained by the hospital and the community. After each fragment is successfully uploaded, IPFS will automatically return the unique cryptographic hash ID (CID) corresponding to that fragment based on the content addressing mechanism.

[0085] Step 2: Calculate the shard hash value and construct the storage Merkle tree: To converge this set of discrete distributed storage hashes into a single point that can represent the topological state of the entire large file space, a storage Merkle tree construction algorithm is run. Each IPFS shard returns an independent hash fingerprint as a base leaf node. These are then expanded and upgraded into pairwise summation hash operations. Let the current storage tree have a total of... During runtime, the algorithm strictly adheres to the following binary topological convergence formula for layer-by-layer upward collapse: ; If the number of nodes in a certain layer is odd, the last node is copied to complete the calculation and the calculation continues. After convergence layer by layer, a unique root node is obtained: Storage Merkle Root. This root node serves as the unique storage path hash value for the entire abnormal vital signs data and is used to represent all the original data content.

[0086] Step 3: Write the storage path hash into the blockchain ledger: Use the storage path hash value (Storage Merkle Root) output in the previous step as the unique data payload and fill it into a lightweight transaction body specifically designed for public health audit ledgers: ; After being digitally signed, the evidence is written into the blockchain ledger to complete the proof.

[0087] Because the blockchain transaction ultimately records only a 32-byte storage path hash value, without containing any heavy original waveform text, the storage burden of the entire blockchain ledger is effectively reduced, perfectly achieving the goal of lightweight storage for the blockchain ledger. This ensures that the consortium blockchain network can maintain millisecond-level consensus recording performance even during peak periods of massive numbers of home-based patients with complications. Furthermore, because the storage Merkle root hash has an extremely one-to-one mapping relationship with the underlying data shards, clinicians or public health auditors can easily access this home follow-up data later. When processing data, the audit engine only needs to use the storage path hash on the chain to piece together each slice in the IPFS network to complete offline reassembly, decryption, and restoration. If the blood sugar or blood pressure value of any slice is tampered with by a hacker during distributed transmission, the offline recalculated storage Merkle root will deviate from the record on the chain, and the verification system will instantly alarm. This step, through this solution, perfectly welds home IoT data collection, on-chain high dynamic frequency control, distributed secure storage, and on-chain lightweight auditing into a seamless and unbreakable technical closed loop.

[0088] Furthermore, once chronic disease management establishes a comprehensive trust defense through cloud-based AI assessment, on-chain evidence chain solidification, community-based voice interaction, and home IoT high-dynamic monitoring, the system enters the ultimate application scenario for maximizing the value of chronic disease assets: cross-institutional diagnosis and treatment referrals and scientific research data steps.

[0089] Phase 1: In the traditional healthcare system, inter-hospital referrals face serious pain points such as "information silos" and "trust deficits." Because of their medical responsibilities, the referring hospital is hesitant to send sensitive patient information and AI decision-making data to external institutions. Meanwhile, the receiving hospital cannot verify the authenticity of offline medical records provided by the referring hospital. By using a referral smart contract to automatically verify the digital identity of the receiving hospital and package the historically accumulated verifiable evidence chain into an encrypted referral form, the anti-counterfeiting features of blockchain and asymmetric encryption technology can be used to achieve a secure, rapid, and compliant one-way flow of medical assets between institutions.

[0090] Specific implementation process: When a patient's condition worsens and triggers an inter-hospital referral request, the HIS system of the transferring hospital initiates a call to the medical consortium blockchain. The referral smart contract is immediately activated. The contract first calls the global identity registry to perform cryptographic public key alignment on the decentralized digital identity (DID) of the receiving hospital in the request packet, verifying whether the hospital is a compliant and registered medical institution. After the identity verification is successful, the referral smart contract automatically indexes the patient's previous on-chain data, the historical verifiable decision evidence chain built in S4, and the referral information generated by AI in this follow-up visit. The system assembles a payload with the purpose (e.g., hypertension complicated by renal failure, recommending emergency transfer to a nephrology specialist). Then, the system calls the asymmetric public key registered on the blockchain by the receiving hospital to perform high-strength asymmetric encryption on the payload, assembling an encrypted referral form. The system also modifies the data access control list (ACL) on the blockchain to grant one-way trust to the receiving hospital. After receiving the encrypted referral form, the receiving hospital can only use its own private key stored in the hardware security module (HSM) to perform one-way decryption and access, thus completing the inter-agency transfer of the medical causal evidence chain in an absolutely secure manner.

[0091] Phase Two: Traditional methods of extracting research data for chronic diseases often employ a "one-size-fits-all" offline packaging approach, completely ignoring the subjective will of patients as data owners and easily leading to infringement disputes. By dynamically verifying the patient's authorization status through on-chain smart contracts, it can be ensured that every research call is within the compliance boundary. Issuing one-time access credentials can restrict the access boundaries of external institutions and prevent research institutions from endlessly extracting data from the dataset.

[0092] The specific implementation process is as follows: An external research institution sends a data access request transaction to the medical consortium blockchain through the research management console, specifying the characteristics of the research sample group it needs (e.g., a follow-up dataset of severe hypertension patients aged 50-60 with diabetes). The dynamic authorization smart contract on the consortium blockchain is triggered, and the contract immediately starts a traversal retrieval algorithm to check the preset privacy transfer status variables of each patient in the batch of sample database in the on-chain privacy authorization ledger. Only when the authorization status of the target patients is determined to be activated (True) will the smart contract dynamically issue a one-time access credential with strong time constraints (the credential is presented in the form of a 256-bit random hexadecimal string) by calculating the combined fingerprint of the current block hash and the research institution's DID inside the virtual machine. This credential serves as the only legitimate token to start the hospital's privacy desensitization engine and is asynchronously issued to the hospital's isolation front-end machine.

[0093] Traditional desensitization methods (such as simply erasing names and ID numbers) completely fail when faced with high-dimensional continuous time series of chronic disease symptoms. Hackers or malicious researchers can precisely "reverse reconstruct" the patient's true identity by aligning these blood pressure and blood sugar waveforms with publicly available smartwatch data. Introducing a homomorphic desensitization AI model based on Generative Adversarial Networks (GANs) allows the system to operate in a fully encrypted (homomorphic encrypted) environment. The GAN generator can perfectly learn the high-dimensional and complex probability distribution of the original chronic disease dataset, thereby generating a set of virtual desensitized medical records that are statistically identical to real medical records, but microscopically synthesized entirely by AI. This fundamentally achieves secure decoupling of data.

[0094] The specific implementation process is as follows: First, the system employs a homomorphic encryption algorithm to perform a fully encrypted mapping of the original chronic disease dataset, ensuring that even if data leakage occurs when loading the AI ​​model's memory, it will result in a jumble of characters. Then, the system activates a homomorphic desensitization AI model based on a generative adversarial network. During runtime, the generator (G) within the model attempts to capture the joint probability distribution of chronic disease features in the encrypted space and generates highly realistic synthetic encrypted medical records. Meanwhile, the discriminator (D) strives to distinguish whether the input sample comes from real patient medical record encrypted text or from the generator's synthetic encrypted text. The two engage in adversarial training in the homomorphic domain, and the core optimization calculation formula is as follows: ; : Represents the core objective function of the minimax game in the operation of the generative adversarial network model. Its ultimate goal is to find a balance point where the discriminator’s ability to distinguish between real and fake objects is maximized, while the generator’s ability to forge objects is minimized (so that the discriminator cannot distinguish between real and fake objects). : indicates that the distribution follows the original real chronic disease dataset. Ciphertext feature vector Perform expected mathematical calculations; : This represents the logarithmic probability score of the discriminator correctly classifying the ciphertext medical record as "true"; : Represents a low-dimensional random noise vector for the input. (follows prior noise distribution) ) Perform expectation calculation; : This indicates that the discriminator will analyze the synthesized ciphertext data generated by the generator. The log probability of being identified as "false".

[0095] By adding rigorously calculated and quantitatively controlled Laplace or Gaussian noise to the synthetic dataset generated by GAN, it can be ensured that even if an attacker has all external public health background information except for a specific patient, they will absolutely not be able to determine whether the patient is in the current dataset by observing the research results. Furthermore, writing all the causal parameters used in this research into the blockchain establishes a non-repudiable post-supervision mechanism, ensuring that the transfer of every bit of chronic disease asset is traceable.

[0096] Specific implementation process: The desensitization engine first calculates the global sensitivity of the current synthetic dataset to external scientific research queries. To achieve the optimal mathematical balance between "removing individual identification features" and "preserving the overall statistical relevance of the dataset," the system activates a Laplace differential privacy mechanism. The engine uses privacy budget parameters preset by the National Health Commission's compliance policy. The algorithm automatically calculates the required noise scale and forcibly superimposes a random mathematical noise following a Laplace distribution onto each output point of the multidimensional vital sign sequence in the synthetic dataset. The probability density of added noise is calculated according to the following formula: ; : Represents the Laplace noise random variable injected into the synthetic chronic disease dataset. The probability density function; : Indicates the maximum global sensitivity of the current chronic disease research query function on adjacent datasets; : This represents the preset differential privacy budget. The smaller the value, the stronger the injected noise, and the privacy protection reaches its maximum exponentially, but it will slightly sacrifice the overall statistical accuracy of a portion of the dataset. : indicates the natural logarithm An exponential function with base 0.5 will, after processing, give the system the final capability. - The de-identified dataset with differential privacy and security rating has been officially released to research institutions for use.

[0097] Full lifecycle audit records are uploaded to the blockchain: Within the same microsecond in the database, the multi-scenario audit tracing module automatically captures the entire causal context of this scientific research event and assembles it into a high-specification audit transaction package. ; The transaction package locks in the data access subject (research institution DID), access time (current block timestamp), access scope (requested data items and authorization status mask), and access result (the hash fingerprint of the final de-identified dataset). The transaction package is recorded across the entire network using the consortium blockchain's PBFT consensus algorithm and permanently pinned to the blockchain ledger, forming an immutable and non-repudiable full lifecycle audit record. This enables this method not only to achieve efficient clinical relay for cross-hospital referrals at the front end, but also to build a privacy computing trust monument for external chronic disease research at the back end, where data is usable but invisible and the entire flow process is fully traceable.

[0098] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising a reference structure" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0099] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for collecting and storing chronic disease follow-up data based on AI and blockchain, characterized by: The method includes the following steps: S1: Acquire multi-source chronic disease follow-up data through the full-scenario collection terminal, use the distributed identity identifier DID to perform on-chain identity authentication and time synchronization on the full-scenario collection terminal, and perform standardized processing on the authenticated data to generate corresponding multi-dimensional chronic disease feature vectors. S2: Input the multidimensional chronic disease feature vector into the central decision AI model for risk assessment, and output the patient's risk score and corresponding follow-up intervention results; S3: While generating the risk score, the decision-related information involved in this assessment is extracted synchronously through the model interpretation module. The decision-related information includes at least a feature vector summary, a model parameter summary, a feature contribution vector used to characterize the degree of contribution of each input feature to the risk score, and the risk score result. S4: Generate a decision path code based on the causal transmission order of the decision association information in the forward propagation process of the central decision AI model, and encapsulate the decision association information into a verifiable decision evidence chain according to the decision path code; S5: Perform cryptographic hash calculation on the verifiable decision evidence chain, and write the generated hash result into the blockchain ledger as a decision evidence record; S6: Based on the follow-up intervention results, control the corresponding follow-up execution terminal to collect incremental data, and verify the access rights of external institutions through the dynamic authorization smart contract deployed on the chain. Based on the decision evidence record, complete the controlled sharing and audit traceability of the corresponding chronic disease follow-up data throughout its entire life cycle.

2. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: S1 specifically includes the following steps: S101: Distributed identity identifiers (DIDs) conforming to W3C standards are allocated and activated through a blockchain network for in-hospital chronic disease terminals, community-level terminals, home IoT device terminals, and scientific research terminals. S102: When each collection terminal uploads chronic disease follow-up data, it uses its corresponding private key to digitally sign the data packet. The blockchain verification node verifies the authenticity and non-repudiation of the data through the digital signature and DID. S103: Employ a streaming computing engine to perform time alignment, missing value compensation, and standardized coding on multi-source heterogeneous chronic disease follow-up data, and construct a multidimensional chronic disease feature vector for risk assessment.

3. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The central decision-making AI model in S2 includes a chronic disease risk stratification model. The specific process of outputting the patient's risk score and corresponding follow-up intervention results is as follows: based on the risk score, the patient is divided into high-risk, medium-risk, and low-risk levels. The corresponding follow-up frequency and intervention strategy are automatically matched according to different risk levels. The large language model is called to automatically assemble and output personalized chronic disease intelligent education text based on the risk level as the follow-up intervention result.

4. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The specific process of writing the generated hash result into the blockchain ledger in S5 includes: performing hash calculations on each evidence node in the verifiable decision evidence chain, constructing a Merkle tree using the obtained hash values, and writing the generated Merkle root as a decision evidence record into the blockchain ledger to establish a unique mapping relationship between the corresponding risk score result and the original input features and model state.

5. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The process of constructing a verifiable decision evidence chain in S4 includes: encapsulating feature vector summaries, model parameter summaries, feature contribution vectors, and risk scoring results into evidence nodes according to the calculation time sequence; generating decision path codes based on the causal mapping flow from input to output in the central decision AI model according to the evidence nodes; and constructing the corresponding verifiable decision evidence chain according to the decision path codes.

6. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The specific process of verifying access permissions through a dynamic authorization smart contract in S6 includes: the dynamic authorization smart contract includes an identity verification module, an authorization scope verification module, an authorization validity period verification module, and an audit record module. When a data access request is received, the dynamic authorization smart contract is invoked to automatically match the requester's DID, the range of the requested data items, and the current block timestamp. Only when the verification results of the above modules meet the preset conditions is a single valid on-chain data access authorization certificate generated.

7. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The method also includes a community chronic disease follow-up step: based on the follow-up intervention results, the community-based AI voice follow-up system is triggered to perform automatic interactive follow-up. Natural language understanding technology is used to convert the follow-up interactive voice into a structured follow-up ledger. The structured follow-up ledger is linked to the corresponding decision evidence record in S5, and the linked index and the follow-up doctor's electronic signature are packaged and written into the blockchain ledger to generate a record of public health performance evaluation.

8. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The method also includes a home-based chronic disease monitoring and early warning step: using a home monitoring terminal to collect the patient's vital signs data in real time, and using an edge computing node to calculate a trend deviation value based on the real-time vital signs data. When the trend deviation value exceeds a preset threshold, an abnormal event is generated, and the abnormal event is associated with the corresponding decision-making record. At the same time, the on-chain smart contract is triggered to dynamically increase the monitoring and on-chain frequency of the home monitoring terminal, and the encrypted abnormal segment vital signs data is stored in the distributed file system IPFS. Only the storage path hash is recorded on the blockchain.

9. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 8, characterized in that: The specific process of recording only the storage path hash on the blockchain is as follows: the encrypted abnormal segment vital signs data is divided into multiple data fragments and uploaded to the distributed file system IPFS. The hash value of each data fragment is calculated and a storage Merkle tree is constructed. The root hash value of the storage Merkle tree is written into the blockchain transaction body as the storage path hash value to achieve lightweight storage of the blockchain ledger.

10. The method for collecting and storing chronic disease follow-up data based on AI and blockchain according to claim 1, characterized in that: The method also includes cross-institutional medical referral and research data utilization steps: When a patient is referred across hospitals, the referring hospital triggers an on-chain referral smart contract based on the referral request. After verifying the DID identity of the receiving hospital, the hospital packages the patient's on-chain data index, historical verifiable decision evidence chain, and referral purpose to generate an encrypted referral form and grants one-way authorization to the receiving hospital. When used for chronic disease research, the method receives data access requests from research institutions. After verifying the patient's authorization status through a dynamic authorization smart contract, a one-time access certificate is generated. A homomorphic desensitization AI model based on generative adversarial networks is called to desensitize the original chronic disease dataset. Differential privacy noise is introduced to remove the patient's individual identification features while retaining the overall statistical correlation of the dataset. The data access subject, access time, access scope, and access results are written into the blockchain ledger to form a full lifecycle audit record.

Images