Blockchain-based medical unit patient whole-process management system

Abstract

This invention relates to the field of medical information management technology, specifically a blockchain-based patient end-to-end management system for medical institutions, comprising: a data aggregation module, a hierarchical decision-making module, and a feedback synchronization module. This invention periodically accesses the original physiological parameters of wearable devices at home, matches them with clinical rehabilitation benchmarks stored during diagnosis to align with the patient's rehabilitation timeline, and outputs dynamic physiological data blocks for each stage. These data are then injected into a blockchain-based multi-stage physiological sign analysis model to quantitatively assess the patient's deviation from clinical rehabilitation, and dynamically trigger limited access permissions to health records accordingly. Clinical warnings are issued based on the rehabilitation deviation values, and follow-up intervention suggestions are received, encapsulated as encrypted receipts, and synchronized to the originating institution to update the post-diagnosis management status. This invention achieves closed-loop management of medical data from collection, warning, authorization to feedback, solving the technical challenges of controlled access to privacy data and dynamic verification of rehabilitation benchmarks in a distributed environment, ensuring the real-time nature and accuracy of medical interventions.

Description

Technical Field

[0001] This invention relates to the field of medical information management technology, specifically a blockchain-based patient end-to-end management system for medical institutions. Background Technology

[0002] With the development of smart healthcare and remote rehabilitation technologies, using wearable IoT devices for post-diagnosis home physiological monitoring has become an important part of end-to-end management. Existing remote monitoring solutions mostly adopt a preset fixed threshold alarm mode, that is, by collecting the patient's real-time physiological parameters (such as heart rate and blood pressure), an alarm is triggered when the parameters exceed general standard values.

[0003] However, the aforementioned existing technologies have the following significant drawbacks in practical applications: First, existing technologies only focus on real-time physiological fluctuations after diagnosis, failing to deeply integrate the rehabilitation benchmarks during diagnosis with post-diagnosis home data. Due to significant differences in the baseline clinical signs and recovery rates among different patients, single-dimensional monitoring detached from clinical benchmarks leads to low early warning accuracy and cannot accurately reflect the patient's true recovery deviations. Second, traditional health record access mechanisms typically employ static authorization or manual approval models, unable to dynamically adjust data access levels based on the urgency of the patient's condition. In the event of potential risks, limited access often leads to untimely follow-up interventions, while excessive authorization results in the leakage of sensitive medical privacy, making it difficult to achieve a dynamic balance between privacy protection and medical treatment. Furthermore, the generation of post-diagnosis follow-up recommendations is often independent of the authorization source and real-time risk status, lacking strong correlation verification based on blockchain consensus mechanisms, resulting in untraceable compliance of follow-up behavior and lag in the update of the entire management process. Existing remote rehabilitation monitoring suffers from a lack of temporal correlation between home vital sign data and clinical evidence benchmarks, and the risk response and data authorization mechanisms are isolated.

[0004] To address this, a blockchain-based patient management system for medical institutions is proposed. Summary of the Invention

[0005] The purpose of this invention is to provide a blockchain-based patient management system for medical institutions to solve the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A blockchain-based end-to-end patient management system for healthcare institutions includes: Data aggregation module: Periodically accesses the raw physiological parameters generated by the wearable device at home through an encrypted channel, and synchronously matches them with the clinical rehabilitation scale stored in the patient's diagnosis stage. Through data fusion processing, it outputs a stage dynamic physiological data block containing the raw physiological parameters and the characteristics of the clinical rehabilitation scale. The hierarchical decision-making module receives the stage dynamic physiological data block and inputs it into the multi-stage physiological sign analysis model to perform consensus calculation. It parses out the original physiological parameters and clinical rehabilitation scale in the stage dynamic physiological data block and calculates the rehabilitation deviation value. If the rehabilitation deviation value reaches a preset threshold, it automatically triggers the limited access permission for the corresponding health record based on the identification information of the stage dynamic physiological data block. Feedback synchronization module: Receives the rehabilitation deviation value and the enabled limited access permission, issues a reminder instruction to the patient based on the rehabilitation deviation value, and receives follow-up intervention suggestions generated based on the limited access permission. It encapsulates the follow-up intervention suggestions into an encrypted receipt and reverse synchronizes them to the originating institution to update the overall management status.

[0007] Preferably, the process of generating a phased dynamic physiological data block includes: establishing a communication link with the home wearable device through the encrypted channel, retrieving raw physiological parameters containing device identifier, collection timestamp, and vital sign values; using the patient identifier in the raw physiological parameters as an index, retrieving a pre-stored clinical rehabilitation scale from the distributed ledger, and extracting the expected rehabilitation curve parameters and clinical threshold benchmarks from the clinical rehabilitation scale; identifying the collection timestamp of the raw physiological parameters, matching the discrete reference values ​​of the corresponding time nodes in the expected rehabilitation curve parameters, and generating an alignment scale component consistent with the dimension of the raw physiological parameters; performing difference calculation and deviation calculation on the raw physiological parameters and the alignment scale component, mapping and extracting the fluctuation characteristics of the raw physiological parameters and the progress characteristics of the clinical rehabilitation scale; and structurally encapsulating the raw physiological parameters, the fluctuation characteristics, the alignment scale component, and the progress characteristics to generate the phased dynamic physiological data block and transmit it to the hierarchical decision module.

[0008] Preferably, the process of parsing and calculating the rehabilitation deviation value includes: before receiving the stage dynamic physiological data block, comparing the hash feature values ​​of the multi-stage physiological sign analysis model through each consensus node to verify the version consistency of the multi-stage physiological sign analysis model in a distributed environment; the multi-stage physiological sign analysis model consists of a data deserialization layer, a normalization mapping layer, a weighted matrix calculation layer, and a gain correction layer; after verification of consistency, receiving the stage dynamic physiological data block, each consensus node reaching a pre-consensus on the stage dynamic physiological data block, and each consensus node locally calling the multi-stage physiological sign analysis model to perform deterministic calculations, perform deserialization processing, and parse and extract the original physiological parameters, the fluctuation characteristics, the alignment scale components, and the progress characteristics; inputting the original physiological parameters and the alignment scale components into a deviation analysis operator to calculate the real-time sign deviation vector; inputting the fluctuation characteristics and the progress characteristics into a stability evaluation operator to generate a rehabilitation trend deviation score; verifying and aggregating the real-time sign deviation vector and the rehabilitation trend deviation score through each consensus node, and outputting a consistent rehabilitation deviation value confirmed by consensus.

[0009] Preferably, the process of automatically triggering limited access permissions for the corresponding health records includes: retrieving a weight allocation matrix corresponding to the sensor type from the multi-stage physiological sign analysis model based on the device identifier in the stage dynamic physiological data block; using the weight allocation matrix to logically verify the rehabilitation deviation value, confirming the calculation validity of the rehabilitation deviation value, and logically comparing the rehabilitation deviation value with the clinical threshold benchmark in the clinical rehabilitation scale to determine whether the rehabilitation deviation value reaches the preset threshold; if the preset threshold is reached, the multi-stage physiological sign analysis model extracts the patient identifier from the stage dynamic physiological data block and generates a limited access token containing the access path and failure count in combination with the current timestamp; and writes the limited access token into the permission control list of the blockchain, activating the limited access permission for the health record corresponding to the patient identifier, and transmitting the activation status and the limited access token to the feedback synchronization module.

[0010] Preferably, the process of issuing reminder instructions and receiving follow-up intervention suggestions includes: the feedback synchronization module receiving the rehabilitation deviation value, matching the corresponding reminder level, converting the rehabilitation deviation value into a reminder instruction containing a warning value and a response time limit, and issuing it to the patient terminal; the response time limit is a global state parameter stored in a smart contract and bound to different reminder levels; receiving a file access request initiated by an external terminal, extracting the digital signature of the external terminal, and matching and verifying it with the limited access token in the permission control list; when the matching and verification pass and the limited access token has not reached the expiration count, granting the corresponding health file reading permission according to the access path; obtaining the diagnosis and treatment guidance information fed back by the external terminal based on the health file, identifying the follow-up action identifier and follow-up parameters in the diagnosis and treatment guidance information, and generating original follow-up intervention suggestions.

[0011] Preferably, the process of the limited access token becoming invalid includes: monitoring the invalidation count and response time limit; when either the invalidation count is reached or the response time limit is exceeded, triggering a blockchain consensus instruction to force the temporary decryption key corresponding to the access path to execute memory zeroing, and synchronously updating the status of the permission control list to unavailable, thereby blocking the external terminal from physically reading the health record.

[0012] Preferably, the process of encapsulating encrypted receipts and updating the overall management status includes: extracting the original follow-up intervention recommendations, associating the rehabilitation deviation value, the call record of the limited access token, and the collection timestamp to construct a follow-up business dataset; extracting the data digest of the follow-up business dataset using a secure hash algorithm, and encrypting and encapsulating the follow-up business dataset using an asymmetric encryption algorithm to generate an encrypted receipt with a unique identifier; sending the encrypted receipt to the distributed ledger node of the originating institution, and writing the encrypted receipt into the block storage space through a consensus mechanism; the originating institution obtaining the change instruction of the encrypted receipt through the blockchain reverse oracle node and parsing the follow-up action identifier, performing a state machine jump on the rehabilitation evaluation field in the overall management status, and completing the business closed loop of the current time sequence node.

[0013] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. By extracting the expected rehabilitation curve from the clinical rehabilitation scale and generating aligned scale components consistent with the original parameter dimensions, the technical challenge of directly comparing home-collected data and in-diagnosis baseline data due to time sequence differences is solved. Combined with the mapping extraction of fluctuation characteristics and progress characteristics, it not only focuses on the absolute deviation of vital sign values, but also couples the rehabilitation stage characteristics and trend stability, providing more complete data support for risk assessment.

[0014] 2. By using consensus nodes to perform hash feature value comparisons on the multi-stage physiological characteristic analysis model, absolute consistency of computational logic in a distributed environment is ensured, reducing the risk of false alarms caused by computational deviations of a single node. Through the "limited access token" triggered by rehabilitation deviation values ​​and the failure count reduction mechanism controlled by smart contracts, "on-demand authorization and disposable access" for health records is realized. While ensuring the efficiency of medical follow-up, the privacy protection problem of sensitive medical data of patients is solved from the underlying protocol level.

[0015] 3. This invention, through the deep coupling of the hierarchical decision-making module and the feedback synchronization module, transforms the consensus-confirmed rehabilitation deviation value into a reminder instruction containing a response time limit, and uses blockchain reverse oracle nodes to capture the follow-up action identifier in the encrypted receipt, driving the state machine of the entire process management status on the initiating institution side to automatically jump; this mechanism realizes closed-loop evidence storage and status synchronization from abnormal vital signs monitoring to expert intervention feedback, effectively improving the real-time performance of post-diagnosis rehabilitation management, the traceability of follow-up behavior, and the efficiency of business collaboration between terminals. Attached Figure Description

[0016] Figure 1 This is an overall flowchart of the blockchain-based patient management system for medical units according to the present invention. Figure 2 This is a flowchart of the dynamic physiological data block generation stage of the present invention; Figure 3 This is a flowchart illustrating how the present invention analyzes and calculates rehabilitation deviation values. Detailed Implementation

[0017] The embodiments of the present invention will now be described in full with reference to the accompanying drawings. It should be understood that the post-heart valve replacement rehabilitation scenario in the embodiments is merely an example and not the sole limitation on the scope of protection. Equivalent modifications to the technical parameters or module logic made by those skilled in the art based on the content of this invention without inventive effort are all within the scope of protection of this invention.

[0018] Please see Figures 1 to 3 This invention provides a blockchain-based end-to-end patient management system for medical institutions, with the following technical solution: A blockchain-based end-to-end patient management system for healthcare institutions includes: Data aggregation module: Periodically accesses the raw physiological parameters generated by the wearable device at home through an encrypted channel, and synchronously matches them with the clinical rehabilitation scale stored in the patient's diagnosis stage. Through data fusion processing, it outputs a stage dynamic physiological data block containing the raw physiological parameters and the characteristics of the clinical rehabilitation scale. The hierarchical decision-making module receives the stage dynamic physiological data block and inputs it into the multi-stage physiological sign analysis model to perform consensus calculation. It parses out the original physiological parameters and clinical rehabilitation scale in the stage dynamic physiological data block and calculates the rehabilitation deviation value. If the rehabilitation deviation value reaches a preset threshold, it automatically triggers the limited access permission for the corresponding health record based on the identification information of the stage dynamic physiological data block. Feedback synchronization module: Receives the rehabilitation deviation value and the enabled limited access permission, issues a reminder instruction to the patient based on the rehabilitation deviation value, and receives follow-up intervention suggestions generated based on the limited access permission. It encapsulates the follow-up intervention suggestions into an encrypted receipt and reverse synchronizes them to the originating institution to update the overall management status.

[0019] Example 1 This embodiment focuses on home rehabilitation management for patients after heart valve replacement surgery. The system of this invention monitors and evaluates the patient's heart rate and exercise tolerance throughout the three months following surgery. In this embodiment, the originating institution refers to the medical node that initially generates and stores the patient's clinical rehabilitation benchmark in the distributed ledger. It also serves as the responsible entity for the closed-loop business process, receiving follow-up feedback and maintaining and updating the overall management status.

[0020] First, refer to Figure 2 The process of generating a phased dynamic physiological data block includes: establishing a communication link with the home wearable device through the encrypted channel, retrieving raw physiological parameters containing device identifier, collection timestamp, and vital sign values; using the patient identifier in the raw physiological parameters as an index, retrieving a pre-stored clinical rehabilitation scale from the distributed ledger, and extracting the expected rehabilitation curve parameters and clinical threshold benchmarks from the clinical rehabilitation scale; identifying the collection timestamp of the raw physiological parameters, matching the discrete reference values ​​of the corresponding time nodes in the expected rehabilitation curve parameters, and generating an aligned scale component with the same dimension as the raw physiological parameters; performing difference calculation and deviation calculation on the raw physiological parameters and the aligned scale component, mapping and extracting the fluctuation characteristics of the raw physiological parameters and the progress characteristics of the clinical rehabilitation scale; and structurally encapsulating the raw physiological parameters, the fluctuation characteristics, the aligned scale component, and the progress characteristics to generate the phased dynamic physiological data block and transmit it to the hierarchical decision module.

[0021] Specifically, the process of generating dynamic physiological data blocks begins with the establishment of a communication link. The system actively establishes bidirectional communication with the medical-grade smart ECG monitoring vest worn by the patient at home through an encrypted channel (such as a mobile network security tunnel based on the TLS 1.3 protocol). Within the acquisition cycle (such as every 5 minutes as a step), the system retrieves raw physiological parameters including device identifier (such as UUID: HD-2025-001), acquisition timestamp (such as 2025-03-08 10:00:00), and vital sign values ​​(such as real-time heart rate 92 beats / min, blood oxygen saturation 96%) to ensure the integrity and timeliness of the raw data.

[0022] After obtaining the raw physiological parameters, the system uses the patient identifier (such as the unique identification code PAT-8848) in the raw physiological parameters as an index to retrieve the clinical rehabilitation scale stored by the patient during hospitalization from the distributed ledger through the smart contract interface of the blockchain node. The clinical rehabilitation scale is stored in the ledger in a key-value pair structure, where the key is a combination of the patient identifier and the stage code, and the value is a set of rehabilitation parameters compressed by Protobuf serialization. This set of rehabilitation parameters defines a mapping array containing timestamp offsets and target vital sign values ​​to improve retrieval efficiency in a restricted ledger environment. During this process, the system parses and extracts the expected rehabilitation curve parameters (which are preset by the clinician and include the static heart rate reference intervals for each postoperative stage) and clinical threshold benchmarks (such as the physiological extreme value range at the 4th week after surgery) from the clinical rehabilitation scale. The system automatically identifies the acquisition timestamp of the original physiological parameters, calculates the offset of the current acquisition time relative to the rehabilitation time axis, and retrieves the reference values ​​of the preceding and following nodes adjacent to the time interval of the acquisition timestamp in the expected rehabilitation curve parameters (e.g., the reference heart rate of the patient on the 28th day after surgery is 75 beats / min). A linear interpolation operator is then used to smooth the reference interval between the two discrete reference values, fitting the theoretical physiological expectation value for the current moment. If the offset exceeds the time range of the mapping array, the nearest discrete reference value is selected as the alignment benchmark. Even when the acquisition time coincides with a discrete reference value node, the system can still determine a unique benchmark value through this interpolation logic, thereby generating an alignment scale component with the same dimension as the original physiological parameters (e.g., a one-dimensional vector structure containing a single sign dimension), providing a benchmark for subsequent accuracy comparisons.

[0023] After time alignment is completed, the data fusion process begins. The system performs difference calculations and deviation calculations on the original physiological parameters (92 beats / min) and the aligned scale component (75 beats / min). For example, the calculated absolute difference is 17, and the relative deviation is approximately 22.7%. The system further maps and extracts the fluctuation characteristics of the original physiological parameters. In this mapping and extraction process, the fluctuation characteristics are calculated using the second-order difference of the heart rate values ​​within a sliding window. The progress characteristics are calculated based on the ratio of the offset of the current acquisition timestamp relative to the rehabilitation start time to the total rehabilitation cycle (i.e., the number of days of rehabilitation completed divided by the total rehabilitation cycle). The system encapsulates the acquired original physiological parameters, fluctuation characteristics, aligned scale component, and progress characteristics according to a set structured protocol (e.g., JSON format) to generate a stage dynamic physiological data block with a unique timestamp. This stage dynamic physiological data block is then transmitted in real-time to the hierarchical decision-making module via the blockchain client's API interface.

[0024] This invention uses a time-series alignment mechanism to encapsulate home monitoring data with personalized clinical rehabilitation benchmarks in a multidimensional way.

[0025] Throughout the process, the system acquires raw physiological parameters containing identifiers, timestamps, and values ​​through an encrypted channel. Using the patient identifier as an index, it retrieves a pre-stored clinical rehabilitation scale from the distributed ledger, extracting the expected rehabilitation curve parameters and clinical threshold benchmarks. Subsequently, it identifies the acquisition timestamps of the raw parameters and matches the discrete reference values ​​of the corresponding nodes in the expected curve, generating an aligned scale component with the same dimension as the raw parameters. Based on this, it performs difference calculations and deviation calculations, mapping and extracting fluctuation features and progress features. Finally, it performs structured encapsulation of the raw parameters, fluctuation features, aligned scale components, and progress features to generate stage dynamic physiological data blocks.

[0026] This invention solves the incomparability problem caused by temporal deviation between home-collected data and in-diagnosis static benchmarks by establishing aligned scale components with consistent dimensions, thus achieving precise alignment between monitoring data and rehabilitation plans. At the same time, by mapping and extracting fluctuation and progress features, the system can not only focus on the instantaneous deviation of vital signs values, but also couple the phased patterns of rehabilitation with the fluctuation trends of vital signs, thereby providing a more complete and clinically valuable data dimension for risk assessment and significantly improving the reliability of risk identification.

[0027] Further, see Figure 3The process of parsing and calculating the rehabilitation deviation value includes: before receiving the stage dynamic physiological data block, comparing the hash feature values ​​of the multi-stage physiological sign analysis model through each consensus node to verify the version consistency of the multi-stage physiological sign analysis model in a distributed environment; the multi-stage physiological sign analysis model consists of a data deserialization layer, a normalization mapping layer, a weighted matrix calculation layer, and a gain correction layer; after verification, receiving the stage dynamic physiological data block, each consensus node reaches a pre-consensus on the stage dynamic physiological data block, and each consensus node locally calls the multi-stage physiological sign analysis model to perform deterministic calculations, perform deserialization processing, and parse and extract the original physiological parameters, the fluctuation characteristics, the alignment scale components, and the progress characteristics; inputting the original physiological parameters and the alignment scale components into the deviation analysis operator to calculate the real-time sign deviation vector; inputting the fluctuation characteristics and the progress characteristics into the stability evaluation operator to generate a rehabilitation trend deviation score; verifying and aggregating the real-time sign deviation vector and the rehabilitation trend deviation score through each consensus node, and outputting a consistent rehabilitation deviation value confirmed by consensus.

[0028] Specifically, the process of parsing and calculating rehabilitation deviation values ​​is executed through consensus within a blockchain network composed of medical institutions, third-party regulatory nodes, and data service providers. Before receiving the phase dynamic physiological data block, each consensus node in the network first initiates an environment consistency check by calculating the SHA-256 hash feature value of the currently locally stored multi-stage physiological sign analysis model and broadcasting it across the entire network for comparison. If the hash values ​​are consistent, it is determined that the model versions running by each node are uniform (e.g., all are v2.1 versions), thereby avoiding inconsistent calculation results due to model deviation. After verification of consistency, each node receives the phase dynamic physiological data block sent by the data aggregation module. Subsequently, each node enters the pre-consensus phase, stores the received data block in a temporary cache area, and uses local computing resources to call the verified multi-stage physiological sign analysis model.

[0029] During the calculation process, each consensus node first performs deserialization processing on the data block encapsulated in JSON format through the data deserialization layer, and parses and restores the original physiological parameters (92 times / min), fluctuation characteristics (+2.5 slope), alignment scale component (75 times / min), and progress characteristics (33.3%) in the aforementioned embodiment; specifically, it first enters the normalization mapping layer to multiply the absolute value of the slope of the fluctuation characteristic 2.5 by the fluctuation conversion coefficient 2 to obtain the fluctuation item score 5; multiply the percentage value of the progress characteristic 33.3% by 10 (corresponding to the 10-point mapping ratio) to obtain the progress item score 3.33; each node calls the weighted matrix calculation layer to input the original physiological parameters and alignment scale component into the deviation analysis operator. The deviation analysis operator obtains the difference 17 through vector subtraction operation (i.e., subtracting the alignment scale component 75 from the original physiological parameter 92), and encapsulates it into a real-time vital sign deviation vector in a one-dimensional mapping space (e.g.,

[17] ). [The square brackets indicate that the value is a one-dimensional vector]. Simultaneously, the fluctuation score and progress score are input into the stability evaluation operator. Specifically, the fluctuation score of 5 is multiplied by a fluctuation weighting coefficient of 0.6 to obtain a weighted fluctuation contribution value of 3.0; simultaneously, the progress score of 3.33 is multiplied by a progress weighting coefficient of 0.4 to obtain a weighted progress contribution value of 1.332; the weighted fluctuation contribution value of 3.0 and the weighted progress contribution value of 1.332 are added to obtain an instantaneous deviation value of 4.332; furthermore, the average deviation score within the historical window period (such as the previous 3 collection cycles) is called through the gain correction layer for moving average correction. The moving average correction generates a dynamic correction coefficient by calculating the rate of change between the current instantaneous deviation value and the historical average (e.g., when the rate of change shows a continuous upward trend, a gain compensation coefficient of 1.07 is assigned) to perform gain compensation on the instantaneous deviation value, ultimately generating a recovery trend deviation score of 4.63 out of 10.

[0030] Each consensus node resubmits the locally calculated real-time vital sign deviation vector and rehabilitation trend deviation score to the consensus protocol layer (e.g., using the Byzantine fault-tolerant algorithm practically implemented by PBFT). To alleviate the conflict between high-frequency data acquisition and PBFT consensus communication overhead, the hierarchical decision-making module adopts a preemptive consensus strategy based on risk level. Each consensus node completes risk determination at its local computing layer: if the rehabilitation deviation value indicates an upward jump in risk level, global real-time consensus based on PBFT is immediately triggered; if the determination result shows that the patient is in a stable risk range, the calculation summary is stored in the local shadow ledger, and the aggregation window size is dynamically adjusted according to the average consensus latency of the current blockchain network. Batch storage is performed after the window expires.

[0031] Each node performs verification aggregation on the received calculation results to determine whether the fixed-point calculation results exceeding a preset proportion (e.g., more than 2 / 3) are completely consistent. The fixed-point calculation converts the original parameters into integer operations by amplifying them by a preset precision multiple (e.g., 10^4 times) and performs uniform precision truncation on the division results. The precision truncation follows a uniform rounding strategy toward zero, that is, directly discarding the remainder after the truncation bit without performing a carry operation. At the same time, when the multi-stage physiological characteristic analysis model performs integer operations, it uniformly calls a fixed-point number library with an arithmetic overflow protection mechanism. When the intermediate value exceeds the preset bit width range, it performs saturation truncation processing instead of looping back. Each consensus node forces the start of a deterministic floating-point instruction set simulator (e.g., a software simulation implementation based on the IEEE 754 standard) during the compilation phase to shield the minor architectural differences that may exist between different physical CPUs during the floating-point to fixed-point conversion process.

[0032] After reaching a consensus, the system outputs the consensus-confirmed consistent rehabilitation deviation value. Specifically, the upper limit of the clinical extreme value of the corresponding physiological dimension is extracted from the clinical rehabilitation scale (e.g., the upper limit of the extreme value is 100 for the heart rate dimension). The absolute value of the real-time vital sign deviation vector

[17] is divided by this upper limit of the clinical extreme value 100 to obtain the vital sign risk item 0.17; the deviation score 4.63 is divided by the total score 10 to obtain the trend risk item 0.463; the proportion of vital sign rehabilitation deviation value is set to 0.3 and the proportion of trend rehabilitation deviation value is set to 0.7. The comprehensive weighted rehabilitation deviation value is output as 0.375 by calculating 0.17×0.3+0.463×0.7.

[0033] This invention achieves the association and encapsulation of home monitoring data and clinical rehabilitation benchmarks through a time-series alignment mechanism.

[0034] The system acquires raw physiological parameters containing timestamps and vital sign values, retrieves the clinical rehabilitation scale from the ledger using the patient identifier as an index, and extracts the parameters of the expected rehabilitation curve. It identifies the timestamps of the raw parameters and matches the discrete reference values ​​of the corresponding nodes in the curve to generate aligned scale components, performs difference calculations and deviation calculations, maps and extracts fluctuation features and progress features, and finally encapsulates them into stage dynamic physiological data blocks in a structured manner.

[0035] This invention solves the problem of incomparability between home dynamic data and in-diagnosis static benchmarks due to time series deviations; by introducing fluctuation and progress characteristics, it reflects the trend and stage of changes in vital signs in multiple dimensions, thereby improving the clinical reference value of subsequent assessment data.

[0036] Furthermore, the process of automatically triggering limited access permissions for the corresponding health records includes: retrieving a weight allocation matrix corresponding to the sensor type from the multi-stage physiological sign analysis model based on the device identifier in the stage dynamic physiological data block; using the weight allocation matrix to logically verify the rehabilitation deviation value, confirming the calculation validity of the rehabilitation deviation value, and logically comparing the rehabilitation deviation value with the clinical threshold benchmark in the clinical rehabilitation scale to determine whether the rehabilitation deviation value reaches the preset threshold; if the preset threshold is reached, the multi-stage physiological sign analysis model extracts the patient identifier from the stage dynamic physiological data block and generates a limited access token containing the access path and failure count in combination with the current timestamp; and writes the limited access token into the permission control list of the blockchain, activating the limited access permission for the health record corresponding to the patient identifier, and transmitting the activation status and the limited access token to the feedback synchronization module.

[0037] Specifically, after obtaining a consensus-confirmed consensus-based rehabilitation deviation value (e.g., 0.375), the current monitoring device is first identified as an "ECG monitoring sensor" based on the device identifier (e.g., UUID: HD-2025-001) in the stage dynamic physiological data block. Based on this, the corresponding weight allocation matrix is ​​retrieved from the local storage space of the multi-stage physiological sign analysis model. When the patient is discharged and the clinical rehabilitation benchmark is recorded, the multi-stage physiological sign analysis model extracts the tangent slope vector of the expected rehabilitation curve at the current stage and performs an outer product operation with the clinical sensitivity coefficient of the sensor type, automatically deconstructing and generating a weight allocation matrix bound to the sensor type. In this embodiment, taking the heart rate dimension as an example, the product of the magnitude of the tangent slope vector and the clinical sensitivity coefficient is used as the unique element of the weight allocation matrix, forming a first-order matrix structure.

[0038] When the system simultaneously monitors multiple physiological dimensions such as heart rate, blood oxygen, and blood pressure, the weight allocation matrix is ​​aggregated from the sub-weight elements corresponding to each dimension. The specific generation process is as follows: The multi-stage physiological sign analysis model first extracts a multi-dimensional slope vector composed of the tangent slopes of the expected recovery curves corresponding to each physiological dimension at the current moment. Then, it retrieves a multi-dimensional sensitivity vector bound to the current sensor hardware model from the system's preset sensor parameter library (e.g., 0.95 for ECG sensors and 0.92 for blood oxygen sensors). The values ​​in the sensor parameter library are pre-calibrated by the medical device manufacturer based on the sensor's signal-to-noise ratio performance. The system performs a dot product operation or diagonalization on the multi-dimensional slope vector and the multi-dimensional sensitivity vector to generate a multi-dimensional diagonal weight matrix matching the number of physiological dimensions. This multi-dimensional weight allocation matrix can dynamically adjust the contribution ratio of each dimension in logical verification based on the patient's sensitivity to different physiological indicators at the current recovery stage (e.g., in the early postoperative period, the patient is more sensitive to heart rate fluctuations, resulting in a higher absolute value of the slope corresponding to heart rate).

[0039] The logical verification is performed by performing a dot product operation on the real-time vital sign deviation vector

[17] and the weight allocation matrix, and determining whether the operation result is consistent with the positive or negative sign of the rehabilitation deviation value of 0.375, thereby verifying the logical consistency between the real-time risk trend and the deviation direction, and confirming that the rehabilitation deviation value falls within the legal scale range of 0 to 1 to ensure the validity of the calculation; after the verification is passed, the system compares the rehabilitation deviation value with the clinical threshold benchmark extracted from the clinical rehabilitation scale, and dynamically establishes the tiered reminder level; for example, in the current stage, [0, 0.2) corresponds to a green warning and [0.35, 1.0] corresponds to a red warning, and the red warning threshold is 0.35. Since the current rehabilitation deviation value of 0.375 has exceeded the threshold, the system determines that a high-risk management process is triggered.

[0040] Once a preset threshold is reached, the multi-stage physiological sign analysis model extracts the patient identifier (PAT-8848) and combines it with the current system timestamp (e.g., 2025-03-08). At 10:05:30, the patient identifier, access path, failure count, and system timestamp are concatenated into strings and hashed. The resulting hash value is digitally signed using the originating institution's private key, generating a limited-access token containing the original plaintext and the signature string. The limited-access token encapsulates the access path of the patient's encrypted health record (such as a content hash address pointing to the distributed storage system IPFS) and the failure count (such as a preset failure count of 3, meaning the token can only be successfully accessed 3 times). The failure count is defined as a global state variable of the smart contract at the blockchain's underlying layer. Whenever an external terminal successfully executes a file access request, the smart contract will automatically trigger a state update instruction, decrementing the failure count corresponding to the token by one until the count reaches zero, at which point the access interface is automatically locked. The consensus node initiates a permission update transaction, writing the limited-access token into the blockchain's permission control list and marking its corresponding permission status as "activated." This operation completes the dynamic authorization of a specific health record under specific conditions.

[0041] Finally, the system transmits the activation status of the limited access token, the recovery deviation value (0.375), and the token string itself to the feedback synchronization module in real time.

[0042] This invention utilizes a limited-use token mechanism based on dynamically generated rehabilitation deviation values ​​to achieve immediate response to high-risk warnings while ensuring the reliability of the authorization logic through weight matrix verification. Combined with failure counting and path limitation technologies, it enables dynamic and precise authorization of patient records that is "triggered on demand and discarded immediately," balancing the real-time nature of medical intervention with the privacy and security of sensitive data.

[0043] Furthermore, the process of issuing reminder instructions and receiving follow-up intervention suggestions includes: the feedback synchronization module receiving the rehabilitation deviation value, matching the corresponding reminder level, converting the rehabilitation deviation value into a reminder instruction containing a warning value and a response time limit, and issuing it to the patient; the response time limit is a global state parameter stored in a smart contract and bound to different reminder levels; receiving a file access request initiated by an external terminal, extracting the digital signature of the external terminal, and matching and verifying it with the limited access token in the permission control list; when the matching and verification pass and the limited access token has not reached the expiration count, granting the corresponding health file reading permission according to the access path; obtaining the diagnosis and treatment guidance information fed back by the external terminal based on the health file, identifying the follow-up action identifier and follow-up parameters in the diagnosis and treatment guidance information, and generating original follow-up intervention suggestions.

[0044] Specifically, upon receiving the rehabilitation deviation value (0.375) and the activated limited access token, the system first initiates the reminder issuance process. The system matches the rehabilitation deviation value (0.375) with the aforementioned dynamically established tiered reminder levels, resulting in a "red high-risk warning." Subsequently, the system automatically encapsulates and generates a reminder instruction that includes the warning value (risk value: 0.375), response time limit (e.g., requiring feedback on status within 30 minutes), and preliminary home treatment guidance. This instruction is then sent to the patient's device (the associated mobile phone of PAT-8848) via mobile push or SMS.

[0045] Meanwhile, after receiving the alert synchronization, external terminals with follow-up permissions (such as the mobile office terminals of community doctors or follow-up staff from the originating institution) initiate a file access request to the blockchain gateway. The system first extracts the digital signature submitted by the external terminal (such as a signature string generated based on the elliptic curve signature algorithm) and verifies it against the public key pre-stored in the blockchain permission control list to confirm the legitimacy of the terminal's identity. After the signature verification is successful, the system further matches and verifies the token identifier carried in the request with the limited access token in the permission control list. If the token status is "activated" and the failure count recorded by the smart contract is greater than 0 (currently 3 times), the system parses and grants access to the patient's health record based on the IPFS access path (content hash address) encapsulated in the token.

[0046] The health records are pre-encrypted using a symmetric key and then stored in IPFS. The corresponding symmetric key is fragmented and encrypted by the originating institution using the public keys of each consensus node and hosted in the blockchain's state database. When an external terminal's access request passes the matching verification, the smart contract automatically triggers a key reconstruction instruction, securely pushing the reconstructed temporary decryption key to the external terminal's memory cache through the encrypted channel, thereby establishing an instantaneous binding relationship between the access path, the limited-use token, and the temporary decryption key. During this process, the external terminal performs streaming decryption in a secure sandbox environment. The decrypted plaintext data is only displayed momentarily in the memory buffer and is prohibited from being written to non-volatile storage.

[0047] After obtaining access to the medical records, the follow-up personnel conduct a comprehensive assessment based on the retrieved historical medical records and the real-time vital signs data of the current warning, and input treatment guidance information online. The system uses a set structured template (such as selecting the follow-up action type via a drop-down menu) or a free text box, employing named entity recognition technology (specifically based on dictionary-based feature word matching) combined with a preset clinical medical knowledge base. The clinical medical knowledge base contains a mapping table between follow-up action keywords and standardized business identification codes. By identifying the core words in the treatment guidance information and matching the corresponding business identification codes, the system automatically parses and identifies the follow-up action identifiers (such as "increase diuretic dosage" or "recommend immediate outpatient follow-up") and follow-up parameters (such as "dosage: 20mg" or "follow-up period: within 24 hours") in the treatment guidance information. The system encapsulates these identified core elements into original follow-up intervention recommendations.

[0048] The clinical medical knowledge base is pre-built by the originating institution according to its corresponding specialty diagnosis and treatment guidelines. Its maintenance is primarily handled by the originating institution's medical quality control node, and the dictionary size dynamically expands as the diagnosis and treatment guidelines are updated. When free text terms not covered by the dictionary are encountered during the identification process, the system automatically activates a semantic similarity calculation engine based on a vector space model. This engine converts the unmatched terms into feature vectors and calculates their cosine similarity to each standard term in the knowledge base. If the calculated highest similarity reaches the confidence threshold automatically set by the system based on the current disease risk level, logical association is performed and mapped to the corresponding business identifier code. Otherwise, the term is marked as a 'to be verified' and suspended in real time to trigger a manual secondary confirmation process by the originating institution. After identification, the parsed follow-up action identifiers and follow-up parameters are uniformly encapsulated in a structured JSON format according to standard procedures.

[0049] This invention ensures the security and reliability of the sensitive medical record access process through a dual verification mechanism of digital signature verification and limited-use tokens; combined with entity recognition-based guidance information parsing, it achieves a rapid closed loop from high-risk warning to the generation of professional diagnostic suggestions, ensuring the clinical accuracy of home intervention actions and the responsiveness of follow-up decisions.

[0050] Furthermore, the process of the limited access token becoming invalid includes: monitoring the invalidation count and response time limit; when either the invalidation count is reached or the response time limit is exceeded, triggering a blockchain consensus instruction to force the temporary decryption key corresponding to the access path to execute memory zeroing, and synchronously updating the status of the permission control list to unavailable, thereby blocking the external terminal from physically reading the health record.

[0051] Specifically, the system monitors the status of the limited access token in real time through a permission monitoring smart contract deployed on the blockchain. In this embodiment, the system continuously polls two circuit breaker indicators corresponding to the token: one is the failure count stored in the global variable of the contract (such as the previously set initial value of 3), and the other is the response time limit from the token generation timestamp (such as the preset 30 minutes). When an external terminal successfully executes a file read transaction, the smart contract will automatically execute the counting logic to reduce the failure count from 3 to 0.

[0052] If the failure count reaches 0 (representing that the 3 authorization slots have been used up) or the difference between the current system timestamp and the token generation timestamp exceeds 30 minutes (representing that the response time limit has been exceeded), the consensus mechanism between blockchain nodes is triggered to issue a revocation command. The revocation command is synchronously captured by the listening agent program of the blockchain node, and the listening agent program initiates a secure memory clearing request with atomic semantics to the operating system. Specifically, the system calls a memory erase function with barrier instructions (such as using the volatile keyword to declare or calling anti-optimization interfaces such as memset_s), forcing the temporary decryption key stored in the memory cache area of ​​the hierarchical decision module, corresponding to the IPFS access path, to perform a memory zeroing operation. That is, the memory address where the key is stored is overwritten with a zero value through system kernel instructions, making the token invalid.

[0053] Subsequently, the smart contract automatically updates the status of the token entry in the permission control list, changing it from "activated" to "unavailable". At this point, even if an external terminal holding the original token string initiates a request to access the token again, the blockchain gateway will intercept the request because the permission control list status verification fails, thus blocking the communication link between the business layer and the storage layer.

[0054] This invention achieves automatic revocation of file access permissions through a two-factor circuit breaker mechanism of failure counting and response time limit; combined with the temporary decryption key memory being reset to zero and the state being updated synchronously triggered by blockchain consensus, it blocks unauthorized access with expired authorization at both the ledger state and hardware memory levels, effectively avoiding the risk of secondary data leakage after the follow-up task is completed, and greatly improving the rigor of medical privacy protection.

[0055] Furthermore, the process of encapsulating encrypted receipts and updating the overall management status includes: extracting the original follow-up intervention recommendations, associating the rehabilitation deviation value, the call record of the limited access token, and the collection timestamp to construct a follow-up business dataset; extracting the data digest of the follow-up business dataset using a secure hash algorithm, and encrypting and encapsulating the follow-up business dataset using an asymmetric encryption algorithm to generate an encrypted receipt with a unique identifier; sending the encrypted receipt to the distributed ledger node of the originating institution, and writing the encrypted receipt into the block storage space through a consensus mechanism; the originating institution obtaining the change instruction of the encrypted receipt through the blockchain reverse oracle node and parsing the follow-up action identifier, performing a state machine jump on the rehabilitation evaluation field in the overall management status, and completing the business closed loop of the current time sequence node.

[0056] Specifically, the system extracts the identified original follow-up intervention recommendations (such as "increase the diuretic dose by 20mg") and reassembles them with the generated recovery deviation value (0.375), the three complete token call logs, and the original collection timestamp of 2025-03-08 10:05:30 to construct a complete follow-up business dataset. The system uses a secure hash algorithm (such as SHA-256) to process the dataset and extract a fixed-length data digest to ensure the immutability of the content. Subsequently, the system uses an asymmetric encryption algorithm (such as using the originating institution's RSA public key) to perform high-strength encryption and encapsulation on the follow-up business dataset, generating a unique encrypted receipt with a digital signature.

[0057] The encrypted receipt is sent to the blockchain node corresponding to the originating institution (such as the valve replacement center where the patient was located before the operation) and written into the block storage space of the distributed ledger through the PBFT consensus protocol. The management system inside the originating institution monitors the ledger changes in real time through the blockchain reverse oracle node. Once a new receipt for the patient (PAT-8848) is captured, the reverse oracle node automatically parses the follow-up action identifier (such as identifying it as "medication adjustment").

[0058] Finally, based on the analysis results, the clinical management backend of the originating institution executes state machine transition logic on the rehabilitation evaluation field in the patient's full rehabilitation process management status: the status is transitioned from "abnormal warning" to "intervention completed", and the follow-up record details of this time node are updated simultaneously.

[0059] This invention achieves a closed loop of evidence storage and business flow for follow-up intervention through state machine transitions driven by a reverse oracle.

[0060] The system extracts original follow-up intervention suggestions and constructs a follow-up business dataset by associating rehabilitation deviation values, accessing token records, and collecting timestamps. It uses a secure hash algorithm to extract data digests and generates encrypted receipts with unique identifiers using an asymmetric encryption algorithm. These receipts are then written to the block storage space corresponding to the originating institution through a consensus mechanism. Finally, the system captures change instructions and parses follow-up action identifiers through a blockchain reverse oracle node, and performs state machine transitions on the rehabilitation evaluation field in the overall management status.

[0061] This invention ensures the immutability and traceability of follow-up records by multidimensionally linking follow-up decisions with original risk data and encrypting and storing the evidence. By utilizing reverse oracle and state machine jump mechanisms, it realizes the automatic triggering of blockchain ledger data to external business logic, effectively solving the problems of delayed feedback information and non-closed-loop business nodes in post-diagnosis management, and significantly improving the collaborative efficiency of cross-institutional follow-up work.

[0062] This invention achieves precise alignment assessment of home-based vital signs with clinical benchmarks through the collaboration of a blockchain consensus architecture and dual-track risk operators. Combined with a limited-use token circuit breaker mechanism and reverse oracle-driven state machine transitions, it constructs an automated business closed loop from high-risk early warning to controlled authorization and then to diagnosis and treatment feedback, significantly improving the collaborative efficiency of cross-institutional follow-up. While ensuring the real-time nature of medical intervention, it also ensures the full traceability and evidence security of patient privacy data.

[0063] Example 2 Using patients who have undergone heart valve replacement surgery and are in the second month (the stable recovery period) as a case study, this study aims to verify how the system can achieve automated monitoring of the entire process and strict control over access to medical records when physiological indicators fluctuate within the normal range.

[0064] On day 45 of rehabilitation, the system retrieved the patient's (PAT-8848) home ECG parameters via an encrypted channel (TLS1.3). The data collection timestamp was 09:00:00 on April 15, 2025, and the vital signs were: real-time heart rate 78 bpm and blood oxygen saturation 98%. The system accessed the clinical rehabilitation scale through a distributed ledger and matched the expected rehabilitation curve discrete reference value for this time point to 76 bpm. After aligning the scale components, the system performed a difference operation to obtain an absolute difference of 2. The system then extracted the fluctuation features and used a sliding window second-order difference to calculate the fluctuation slope as +0.1 (at an extremely low fluctuation level). The progress feature was calculated to be 50.0%.

[0065] After receiving the phase dynamic physiological data block and verifying the hash consistency of the multi-stage physiological sign analysis model, each consensus node locally calls the multi-stage physiological sign analysis model to perform deterministic calculations. The system first performs deserialization processing on the phase dynamic physiological data block, parsing and extracting the original physiological parameters (78 beats / min), fluctuation characteristics (+0.1 slope), alignment scale components (76 beats / min), and progress characteristics (50.0%) of the current stable recovery period. Each node inputs the original physiological parameters and alignment scale components into the deviation analysis operator, and obtains the real-time sign deviation vector through vector subtraction. [2] Meanwhile, the fluctuation feature and the schedule feature are input into the stability evaluation operator and normalization mapping is performed: the absolute value of the slope of the fluctuation feature is multiplied by the fluctuation conversion coefficient 2 to obtain the fluctuation item score of 0.2; the percentage value of the schedule feature is multiplied by 10 to obtain the schedule item score of 5; then, the fluctuation item score is multiplied by the fluctuation weighting coefficient 0.6 to obtain the weighted fluctuation contribution value of 0.12; at the same time, the schedule item score is multiplied by the schedule weighting coefficient 0.4 to obtain the weighted schedule contribution value of 2; the weighted fluctuation contribution value and the weighted schedule contribution value are added to obtain the instantaneous deviation value of 2.12.

[0066] Based on this, the system calls the average deviation score within the historical window period for moving average correction; since the rate of change between the current real-time deviation value and the historical average in the current stable rehabilitation period tends to 0, the dynamic correction coefficient generated by the system is 1.0 (i.e. no gain compensation), and finally generates a rehabilitation trend deviation score of 2.12 out of 10; finally, each consensus node enters the verification and aggregation stage, extracts the upper limit of the clinical extreme value of the heart rate dimension 100 from the clinical rehabilitation scale, divides the absolute value of the real-time vital sign deviation vector [2] by the upper limit of the clinical extreme value 100 to obtain the vital sign risk item 0.02; divides the deviation score 2.12 by the total score 10 to obtain the trend risk item 0.212; sets the proportion of vital sign rehabilitation deviation value to 0.3 and the proportion of trend rehabilitation deviation value to 0.7, and outputs the comprehensive weighted consistency rehabilitation deviation value of 0.154 by calculating 0.02×0.3+0.212×0.7.

[0067] The system retrieves the corresponding weight allocation matrix from the multi-stage physiological sign analysis model based on the device identifier (UUID: HD-2025-001). At this time, since the patient is in the stable period of the 45th day of rehabilitation, the multi-stage physiological sign analysis model extracts the tangent slope vector of the rehabilitation curve that tends to be flat in this stage, and combines it with the sensitivity coefficient of the electrocardiogram sensor to update and generate the weight allocation matrix of the current stage through the outer product operation. The system performs a dot product operation on the real-time sign deviation vector [2] and the updated matrix, and determines that the positive or negative sign of the operation result is consistent with the rehabilitation deviation value of 0.154, and the verification is passed.

[0068] Subsequently, the system compares the rehabilitation deviation value of 0.154 with the preset red warning threshold of 0.35. Since 0.154 < 0.35, the system determines that the patient is currently in the "normal rehabilitation zone" and does not trigger the limited access token generation command, thereby physically blocking unnecessary access to the patient's health records by external terminals in a risk-free state.

[0069] The feedback synchronization module receives the weight value and determines the alert level as "green normal monitoring" based on the mapping table; the system sends an alert instruction to the patient's end: "Recovery progress is more than halfway complete, indicators are stable, please continue to maintain this."

[0070] Meanwhile, since no access-limited token was generated, the access control list remained in its original state; the system automatically constructed a phased health snapshot containing a recovery deviation value of 0.154, generated a summary and wrote it into the block; the originating institution resolved the phased receipt through the reverse oracle, and its clinical management backend state machine maintained the "normal recovery in progress" state.

[0071] The above embodiments are only used to illustrate the technical essence of the present invention. Those skilled in the art should understand that any modifications and substitutions made to the mathematical operators, weighting ratios, consensus algorithms, etc., involved therein, without departing from the blockchain regulatory framework and dynamic authorization logic of the present invention, fall within the protection scope defined by the claims of the present invention.

Claims

1. A blockchain-based patient management system for medical institutions, characterized in that: include: Data aggregation module: Periodically accesses raw physiological parameters generated by home wearable devices through an encrypted channel, and synchronously matches them with the clinical rehabilitation scale stored in the patient's diagnosis stage. It identifies the collection timestamp of the raw physiological parameters, matches the discrete reference values ​​of the expected rehabilitation curve parameters in the clinical rehabilitation scale with the corresponding time nodes, uses a linear interpolation operator to generate aligned scale components with the same dimension as the raw physiological parameters, performs difference calculation and deviation calculation, maps and extracts fluctuation features and progress features, and outputs a stage dynamic physiological data block containing the raw physiological parameters and the clinical rehabilitation scale features through data fusion processing. Hierarchical decision-making module: By broadcasting and comparing the hash feature values ​​of the multi-stage physiological sign analysis model across the entire network through each consensus node, the module verifies the version consistency of the multi-stage physiological sign analysis model in a distributed environment; after verification, the module receives the stage dynamic physiological data block and inputs it into the multi-stage physiological sign analysis model to perform consensus calculation, parses out the original physiological parameters and clinical rehabilitation scale in the stage dynamic physiological data block, and calculates the rehabilitation deviation value. If the rehabilitation deviation value reaches a preset threshold, the patient identifier in the stage dynamic physiological data block is extracted according to the identifier information of the stage dynamic physiological data block, and a limited access token containing the access path and failure count is generated by combining the current timestamp. The limited access token is written into the permission control list of the blockchain and the limited access permission for the corresponding health record is automatically triggered. Feedback Synchronization Module: Receives the rehabilitation deviation value and the enabled limited access permission, issues a reminder instruction to the patient based on the rehabilitation deviation value, and receives follow-up intervention suggestions generated based on the limited access permission. It encapsulates the follow-up intervention suggestions into an encrypted receipt and reverse synchronizes it to the originating institution. The originating institution obtains the change instruction of the encrypted receipt through a blockchain reverse oracle node and parses the follow-up action identifier. It then performs a state machine transition on the rehabilitation evaluation field in the overall management status to update the overall management status.

2. The blockchain-based patient management system for medical units according to claim 1, characterized in that, The process of generating a phased dynamic physiological data block includes: establishing a communication link with the home wearable device through the encrypted channel, retrieving raw physiological parameters containing device identifier, collection timestamp, and vital sign values; using the patient identifier in the raw physiological parameters as an index, retrieving a pre-stored clinical rehabilitation scale from the distributed ledger, and extracting the expected rehabilitation curve parameters and clinical threshold benchmarks from the clinical rehabilitation scale; identifying the collection timestamp of the raw physiological parameters, matching the discrete reference values ​​of the corresponding time nodes in the expected rehabilitation curve parameters, and generating an alignment scale component consistent with the dimension of the raw physiological parameters; performing difference calculation and deviation calculation on the raw physiological parameters and the alignment scale component, mapping and extracting the fluctuation characteristics of the raw physiological parameters and the progress characteristics of the clinical rehabilitation scale; and structurally encapsulating the raw physiological parameters, the fluctuation characteristics, the alignment scale component, and the progress characteristics to generate the phased dynamic physiological data block and transmit it to the hierarchical decision module.

3. The blockchain-based patient management system for medical units according to claim 2, characterized in that, The process of parsing and calculating the rehabilitation deviation value includes: before receiving the stage dynamic physiological data block, comparing the hash feature values ​​of the multi-stage physiological sign analysis model through each consensus node to verify the version consistency of the multi-stage physiological sign analysis model in a distributed environment; the multi-stage physiological sign analysis model consists of a data deserialization layer, a normalization mapping layer, a weighted matrix calculation layer, and a gain correction layer; after verification of consistency, receiving the stage dynamic physiological data block, each consensus node reaching a pre-consensus on the stage dynamic physiological data block, and each consensus node locally calling the multi-stage physiological sign analysis model to perform deterministic calculations, perform deserialization processing, and parse and extract the original physiological parameters, the fluctuation characteristics, the alignment scale components, and the progress characteristics; inputting the original physiological parameters and the alignment scale components into the deviation analysis operator to calculate the real-time sign deviation vector; inputting the fluctuation characteristics and the progress characteristics into the stability evaluation operator to generate a rehabilitation trend deviation score; verifying and aggregating the real-time sign deviation vector and the rehabilitation trend deviation score through each consensus node, and outputting a consistent rehabilitation deviation value confirmed by consensus.

4. The blockchain-based patient management system for medical units according to claim 1, characterized in that, The process of automatically triggering limited access permissions for the corresponding health records includes: retrieving a weight allocation matrix corresponding to the sensor type from the multi-stage physiological sign analysis model based on the device identifier in the stage dynamic physiological data block; using the weight allocation matrix to logically verify the rehabilitation deviation value, confirming the calculation validity of the rehabilitation deviation value, and logically comparing the rehabilitation deviation value with the clinical threshold benchmark in the clinical rehabilitation scale to determine whether the rehabilitation deviation value reaches the preset threshold; if the preset threshold is reached, the multi-stage physiological sign analysis model extracts the patient identifier from the stage dynamic physiological data block and generates a limited access token containing the access path and failure count in combination with the current timestamp; and writes the limited access token into the permission control list of the blockchain, activating the limited access permission for the health record corresponding to the patient identifier, and transmitting the activation status and the limited access token to the feedback synchronization module.

5. The blockchain-based patient management system for medical units according to claim 4, characterized in that, The process of issuing reminder instructions and receiving follow-up intervention suggestions includes: the feedback synchronization module receiving the rehabilitation deviation value, matching the corresponding reminder level, converting the rehabilitation deviation value into a reminder instruction containing a warning value and a response time limit, and issuing it to the patient; the response time limit is a global state parameter stored in a smart contract and bound to different reminder levels; receiving a file access request initiated by an external terminal, extracting the digital signature of the external terminal, and matching and verifying it with the limited access token in the permission control list; when the matching and verification pass and the limited access token has not reached the expiration count, granting the corresponding health file reading permission according to the access path; obtaining the diagnosis and treatment guidance information fed back by the external terminal based on the health file, identifying the follow-up action identifier and follow-up parameters in the diagnosis and treatment guidance information, and generating original follow-up intervention suggestions.

6. The blockchain-based patient management system for medical units according to claim 5, characterized in that, The process of the limited access token becoming invalid includes: monitoring the invalidation count and response time limit; when either the invalidation count is reached or the response time limit is exceeded, triggering a blockchain consensus instruction to force the temporary decryption key corresponding to the access path to execute memory zeroing, and synchronously updating the status of the permission control list to unavailable, thereby blocking the external terminal from physically reading the health record.

7. The blockchain-based patient management system for medical units according to claim 5, characterized in that, The process of encapsulating encrypted receipts and updating the overall management status includes: extracting original follow-up intervention suggestions, associating the rehabilitation deviation value, the call record of the limited access token, and the collection timestamp to construct a follow-up business dataset; extracting the data digest of the follow-up business dataset using a secure hash algorithm, and encrypting and encapsulating the follow-up business dataset using an asymmetric encryption algorithm to generate an encrypted receipt with a unique identifier; sending the encrypted receipt to the distributed ledger node of the originating institution, and writing the encrypted receipt into the block storage space through a consensus mechanism; the originating institution obtaining the change instruction of the encrypted receipt through the blockchain reverse oracle node and parsing the follow-up action identifier, executing a state machine jump on the rehabilitation evaluation field in the overall management status, and completing the business loop of the current time sequence node.

Images