Cloud edge end collaborative based home medical device control system

Abstract

Embodiments of the present disclosure disclose a cloud edge-end collaborative home medical device control system. A specific implementation of the system includes an acquisition terminal, an edge processing server, a cloud server and an application terminal, wherein: the acquisition terminal is configured to acquire multi-modal health data; the edge processing server is configured to preprocess the multi-modal health data; the cloud server is configured to: integrate the edge health features with pre-acquired clinical data; generate corresponding prediction curves and dynamic risk levels; generate an explainability report and an intervention instruction; the edge processing server is configured to send the explainability report and the intervention instruction to the application terminal; and the application terminal is configured to control the home medical device to perform corresponding personalized operations. The implementation reduces the control response time of the home medical device control system.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, specifically to a home medical device control system based on cloud-edge-device collaboration. Background Technology

[0002] Currently, home medical devices (such as smart blood glucose meters and wearable ECG monitoring devices) are becoming increasingly common, and health management services are showing a trend of extending from hospitals to homes. Existing technical solutions typically adopt the following two architectures: one is a centralized cloud processing architecture, which uploads all health data to the cloud for calculation and analysis; the other is a purely terminal local processing architecture, which relies on the device's own computing power to complete simple analysis.

[0003] However, when using the above methods to control home medical devices, the following technical problems often exist: Existing technologies use a centralized processing architecture to upload and process multimodal health data, resulting in huge network bandwidth pressure and excessively long data processing links, which wastes system resources and causes home medical devices to have excessively long response times to control commands, wasting a lot of time resources.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a cloud-edge-device collaborative home medical device control system to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a home medical device control system based on cloud-edge-device collaboration, including: an acquisition terminal, an edge processing server, a cloud server, and an application terminal, wherein: the acquisition terminal is configured to acquire multimodal health data; the edge processing server is configured to preprocess the multimodal health data to generate edge health features; the cloud server is configured to: integrate the edge health features with pre-acquired clinical data to generate a dynamic multimodal dataset; generate a corresponding prediction curve and dynamic risk level based on the health feature vector corresponding to the dynamic multimodal dataset; generate an interpretability report and intervention instructions based on the prediction curve, the dynamic risk level, and a pre-constructed medical knowledge graph; the edge processing server is configured to, in response to receiving the interpretability report and intervention instructions generated by the cloud, send the interpretability report and intervention instructions to the application terminal to generate a dynamic health profile; the application terminal is configured to control the home medical device to perform corresponding personalized operations based on the dynamic health profile.

[0008] The various embodiments of this disclosure have the following beneficial effects: Through the cloud-edge-device collaborative home medical device control system of some embodiments of this disclosure, the system resources of the home medical device control system are optimized, reducing the system's control response time. Specifically, the reasons for unreasonable system resource configuration and excessively long control response time in home medical device control systems are: traditional home medical device control systems adopt a centralized processing architecture, resulting in excessive cloud computing load and high data transmission latency; at the same time, the lack of edge-side preprocessing and privacy computing capabilities causes raw sensitive data to be transmitted over long distances over the network, increasing communication overhead and affecting control real-time performance. Based on this, the cloud-edge-device collaborative home medical device control system of some embodiments of this disclosure includes an acquisition terminal, an edge processing server, a cloud server, and an application terminal. First, the acquisition terminal is configured to acquire multimodal health data. This achieves comprehensive collection of multimodal health data of the target user, providing a complete data foundation for health analysis and solving the problem of inaccurate assessment from a single data source. Then, the edge processing server is configured to preprocess the multimodal health data to generate edge health features. By preprocessing data on the edge processing server, data transmission volume is reduced, user privacy is protected, and standardized input is provided for cloud analysis. Then, the cloud server is configured to integrate the edge health features with pre-acquired clinical data to generate a dynamic multimodal dataset. Deeply fusing edge health features with pre-acquired clinical data constructs a dataset comprehensively reflecting health status, laying the foundation for precise analysis. Based on the health feature vectors corresponding to the dynamic multimodal dataset, corresponding prediction curves and dynamic risk levels are generated. The generated prediction curves are used to predict the development trend of health indicators, achieving a leap from static assessment to dynamic prediction and identifying health risks in advance. Based on the prediction curves, dynamic risk levels, and a pre-constructed medical knowledge graph, interpretable reports and intervention instructions are generated. The pre-constructed medical knowledge graph is used to verify the medical rationality of decisions, outputting credible solutions with both operational suggestions and evidence support. Next, the edge processing server is configured to, in response to receiving the interpretable reports and intervention instructions generated in the cloud, send them to the application terminal to generate a dynamic health profile. This process transforms professional medical data into intuitive and visual health reports, making it easier for doctors and patients to understand their current health status and future risks. Finally, the application terminal is configured to control home medical devices to perform corresponding personalized operations based on the dynamic health profile. This achieves a closed loop from multimodal health data analysis to home medical device control, enabling home medical devices to automatically adjust control schemes based on real-time health conditions, significantly reducing system control response time. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0010] Figure 1 This is a schematic diagram of the structure of some embodiments of a home medical device control system based on cloud-edge-device collaboration according to the present disclosure. Detailed Implementation

[0011] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0012] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0013] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0014] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0015] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0016] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0017] refer to Figure 1 The diagram illustrates the structure of some embodiments of a cloud-edge-device collaborative home medical device control system according to the present disclosure. This cloud-edge-device collaborative home medical device control system includes an acquisition terminal 1, an edge processing server 2, a cloud server 3, and an application terminal 4.

[0018] In some embodiments, the acquisition terminal 1 can be configured to acquire multimodal health data. This multimodal health data can be a collection of data from multiple dimensions collected by different sensors. For example, the multimodal health data may include: heart rate time-series data collected by a smart bracelet, blood glucose data collected by a blood glucose monitor, and medical record text data obtained from an electronic medical record system. The acquisition terminal 1 can refer to smart hardware and applications deployed on the user side for collecting raw health data; the acquisition terminal may include: a smartwatch, a blood glucose monitor, and an electronic medical record app.

[0019] In some embodiments, the edge processing server 2 is configured to preprocess the multimodal health data to generate edge health features. The edge processing server 2 can be a locally deployed server that processes the multimodal health data acquired by the terminal nearby, balancing real-time performance and privacy protection; for example, a home gateway may have a built-in edge server. The edge health features can be standardized, de-identified feature data generated after processing by the edge processing server.

[0020] In some optional implementations of certain embodiments, the edge processing server 2 can preprocess the multimodal health data through the following steps to generate edge health features: The first step involves the edge processing server receiving the multimodal health data and cleaning and correcting outliers to generate a regularized time-series dataset. This regularized time-series dataset can be a dataset of cleaned and corrected multimodal health data, sorted by timestamp. In practice, firstly, duplicate data is removed from the multimodal data (e.g., heart rate data, electronic medical record text), and outliers deviating from the normal range are corrected using interpolation. Then, the regularized time-series dataset is generated by sorting by timestamp.

[0021] The second step involves text annotation of the unstructured text in the aforementioned regularized time-series dataset to generate standardized text data. This unstructured text can be health-related text data without a fixed format, such as symptom descriptions in electronic medical records. The standardized text data can be text data that has been annotated and converted to a uniform format. In practice, firstly, text (e.g., "nighttime insomnia") is extracted from the regularized time-series data. Then, the text type and content are annotated according to a medical dictionary. Finally, it is converted into standardized text data. For example, "morning fatigue" is annotated as structured data of "symptom-fatigue-morning onset".

[0022] The third step involves aligning the numerical data and standardized text data from the regularized time-series dataset to generate a spatiotemporally aligned dataset. The numerical data can be quantifiable health indicators (e.g., blood pressure). The spatiotemporally aligned dataset can be a dataset where numerical and text data are associated along the same time dimension. In practice, first, the numerical data (e.g., blood oxygen saturation at a certain time point) is extracted from the regularized time-series dataset. Then, it is matched with the corresponding standardized text (e.g., "measured after exercise"). Finally, the spatiotemporally aligned dataset is generated by associating the data by timestamps.

[0023] The fourth step involves performing differential privacy processing on the sensitive information in the aforementioned spatiotemporally aligned dataset to generate a de-identified local feature set. This sensitive information can be health data that can directly or indirectly identify a specific individual (e.g., name, ID number, date of birth). The de-identified local feature set is a set of local health features that have undergone differential privacy processing to remove sensitive information. In practice, first, the sensitive information in the spatiotemporally aligned data (e.g., name, ID number) is identified. Then, noise addition techniques are used to blur the sensitive fields. Finally, the de-identified local feature set is generated. For example, "Zhang San, heart rate 70" is processed to "Anonymous user, heart rate 70±2".

[0024] The fifth step involves extracting short-term trend statistics from the aforementioned desensitized local feature set to encapsulate them as initial borderline health features. These short-term trend statistics can be short-term change indicators extracted from the desensitized local feature set, such as the standard deviation and mean of heart rate variability over the past 6 hours. The initial borderline health features can be the basic features used to encapsulate the short-term trend statistics, such as the feature combination of "daily average heart rate 75 beats / min + blood glucose fluctuation 0 mmol / L". In practice, firstly, the short-term trend statistics are determined based on the short-term trend statistics (e.g., 72-hour heart rate) in the desensitized local feature set. Finally, the short-term trend statistics are encapsulated as initial borderline health features.

[0025] Step 6: Add data quality labels to the initial edge health features to establish them as edge health features. These data quality labels can be labels indicating data completeness and accuracy, such as "completeness 95%". In practice, first, determine the completeness and accuracy of the initial edge health features (e.g., data missing rate 3%). Then, generate the corresponding quality labels. Finally, combine them into an edge health feature. For example, "72-hour average heart rate 72 beats / min + data completeness 97%".

[0026] In some embodiments, the cloud server 3 described above can be configured as follows: The first step involves integrating the aforementioned borderline health features with pre-acquired clinical data to generate a dynamic multimodal dataset. The cloud server 3 mentioned above can be a core computing server deployed in the cloud. The pre-acquired clinical data can be historical medical records from a hospital system, including diagnostic information and laboratory test information. The dynamic multimodal dataset can be a dataset that fuses borderline health features (dynamic) with pre-acquired clinical data. In practice, the cloud server 3 can integrate the aforementioned borderline health features with pre-acquired clinical data to generate a dynamic multimodal dataset through the following steps: Sub-step one involves spatiotemporally aligning the aforementioned borderline health features with the aforementioned clinical data to obtain an aligned multi-source dataset. This aligned multi-source dataset can be a dataset that matches borderline health features with clinical data along spatiotemporal dimensions.

[0027] Sub-step two involves constructing a corresponding panoramic timeline based on the aligned multi-source dataset. This panoramic timeline can be a complete sequence of health events strung together in chronological order. For example, a health trajectory strung together in chronological order from medical diagnosis to daily monitoring. In practice, first, the time nodes of the aligned multi-source data are determined. Then, health events and indicators are strung together in chronological order. Finally, a panoramic timeline is formed. For example, a complete trajectory strung together daily for "medical diagnosis -> daily blood pressure -> medication records".

[0028] Step three involves imputing missing values ​​in the panoramic timeline to obtain a continuous health record sequence. These missing values ​​can be blank information not collected or recorded in the aligned multi-source dataset corresponding to the panoramic timeline. In practice, first, missing values ​​in the panoramic timeline are identified. Then, medical rules or interpolation methods are used to impute them (e.g., using historical averages to impute missed blood glucose measurements). Finally, a continuous health record sequence is obtained. For example, imputing three days of missed blood pressure measurements creates a blood pressure sequence without breaks.

[0029] Sub-step four involves generating primary statistical features by determining the window statistics for the aforementioned continuous health record sequence. These window statistics can be quantitative statistical indicators within a fixed time window, such as the average blood glucose level over 24 hours or the maximum blood pressure over 7 days. The primary statistical features can be basic features generated based on the window statistics, such as the average daily heart rate or the weekly range of blood lipid fluctuations. In practice, first, a fixed time window (e.g., 24 hours) is set. Then, statistics such as the mean and standard deviation of the data within the window are determined. Finally, the primary statistical features are generated.

[0030] Sub-step five involves constructing time-series interaction terms based on the aforementioned primary statistical features to obtain cross-modal features. These time-series interaction terms can be the correlation features between different indicators in the time dimension, such as the time-series correlation between blood glucose changes and insulin dosage. The cross-modal features can be features that fuse the interaction relationships of multimodal data (e.g., blood glucose changes and insulin dosage). For example, the cross-modal features could be the time-series correlation features between the rate of blood glucose change and insulin dosage. In practice, firstly, time-series interaction relationships are constructed based on primary statistical features (e.g., blood glucose, insulin dosage) to generate cross-modal features, such as the time-series correlation features between the rate of blood glucose change and insulin dosage.

[0031] Sub-step six involves generating semantically enhanced features based on the aforementioned cross-modal features and the aforementioned medical knowledge graph. The medical knowledge graph can be a structured database storing medical concepts and their associations, such as an association graph for hypertension, hyperlipidemia, and cardiovascular diseases. The semantically enhanced features can be features that supplement semantic associations by combining them with the medical knowledge graph. For example, the semantically enhanced features could be features that label the association between "elevated blood sugar" and "diabetes." In practice, firstly, the cross-modal features are matched with the medical knowledge graph. Then, the medical semantic associations of the features are supplemented (e.g., disease associations are labeled). Finally, semantically enhanced features are generated, for example, associating the feature "elevated blood lipids" with the semantic meaning of "risk of atherosclerosis."

[0032] Sub-step seven involves integrating the aforementioned primary statistical features, cross-modal features, and semantic enhancement features into a dynamic multimodal dataset. In practice, this can be achieved by encapsulating and integrating the three types of features—primary statistical features, cross-modal features, and semantic enhancement features—in a unified format to generate a dynamic multimodal dataset.

[0033] Optionally, the aforementioned cloud server 3 can be configured to generate a health feature vector through the following steps: Step one involves separating text sequence data, image data, and time-series signal data from the aforementioned dynamic multimodal dataset. The text sequence data can be structured text sequences from the dynamic multimodal dataset, such as electronic medical record content. The image data can be medically relevant visual image data, such as lung CT images. The time-series signal data can be continuously acquired physiological signal data over time, such as 24-hour electrocardiograms or continuous glucose monitoring curves.

[0034] Step two involves encoding the aforementioned text sequence data using a pre-trained medical language model to obtain text feature vectors. This pre-trained medical language model can be a natural language processing model trained on a large amount of medical text, taking text sequences as input and outputting text feature vectors. For example, the pre-trained medical language model could be a BERT model. The text feature vectors can be numerical vectors encoded from the text sequence data.

[0035] Step 3: Use a deep neural network to extract features from the image data to obtain image feature vectors. These image feature vectors can be numerical vectors derived from the extracted features of the image data. The deep neural network can be a ResNet.

[0036] Step four: Encode the aforementioned time-series signal data using a recurrent neural network to obtain a time-series feature vector. The time-series feature vector is the numerical vector of the encoded time-series signal data. The recurrent neural network can be an LSTM.

[0037] Step 5: Project the aforementioned text feature vectors, image feature vectors, and temporal feature vectors onto a unified dimensional space to generate an aligned multimodal feature set. This aligned multimodal feature set can be a collection of the aforementioned text feature vectors, image feature vectors, and temporal feature vectors projected onto the same dimension. In practice, this can be achieved through linear projection to transform them into the same dimension (e.g., 512 dimensions) to generate the aligned multimodal feature set.

[0038] Step six: Input the above-mentioned aligned multimodal feature set into a pre-trained fusion network to generate preliminary fused features. The fusion network can be a neural network pre-trained on a large amount of medical data for fusing multimodal features, such as a cross-modal Transformer fusion model. The preliminary fused features can be intermediate features resulting from the processing of the aligned multimodal features by the pre-trained fusion network.

[0039] Step seven involves normalizing and linearly projecting the preliminary fused features to generate a health feature vector. This health feature vector can be a low-dimensional numerical vector generated from encoding multimodal health data, used to describe health status. First, the preliminary fused features are normalized. Then, the dimension and distribution are adjusted using linear projection. Finally, the health feature vector is generated.

[0040] The second step involves generating corresponding prediction curves and dynamic risk levels based on the health feature vectors corresponding to the aforementioned dynamic multimodal dataset. The prediction curves can reflect future trends in health indicators. The dynamic risk levels can be real-time updated health risk classifications, such as "low, moderate, and high" hypertension risk levels that fluctuate with blood pressure. In practice, the cloud server 3 can generate corresponding prediction curves and dynamic risk levels based on the health feature vectors corresponding to the aforementioned dynamic multimodal dataset through the following steps: Sub-step one involves generating a corresponding historical state sequence by constructing the time-series data corresponding to the aforementioned health feature vectors. This time-series data can be a set of health feature vectors sorted by time. For example, a daily blood pressure feature vector sequence at 8 AM. The historical state sequence can be time-series data of past health states, such as a sequence composed of daily health feature vectors from the past 30 days. In practice, first, health feature vectors (e.g., daily blood glucose vectors) are extracted. Then, they are sorted according to the collection time to generate the historical state sequence.

[0041] Sub-step two involves time-encoding the aforementioned historical state sequence to generate a time-aware sequence containing absolute location and relative time interval information. This time encoding can be the conversion of time information into numerical features. The absolute location can be a fixed point in time on the timeline (e.g., 10:00 AM on May 1, 2025). The relative time interval information can be the time difference between adjacent data points, such as a numerical record of two blood glucose measurements taken 2 hours apart. The time-aware sequence can be a state sequence including both absolute time and interval information.

[0042] Sub-step three involves encoding the aforementioned time-aware sequence to generate a deep time-series representation with dependencies. These dependencies can be correlations between preceding and subsequent health states. The deep time-series representation can be a high-dimensional feature encoding time dependencies; for example, it could be a high-dimensional vector representing a three-day consecutive increase in blood pressure. In practice, the process involves first inputting the time-aware sequence, then encoding the time dependencies using a Transformer model, and finally generating the deep time-series representation.

[0043] Sub-step four involves determining the prediction curve corresponding to the aforementioned deep time series representation. In practice, an LSTM regression model can be used to generate the prediction curve.

[0044] Sub-step five involves comparing the predicted curve with pre-acquired standard threshold information to generate a threshold comparison result. The standard threshold information can be a range of medical standard health indicators, such as the normal fasting blood glucose range of 3.9-6.1 mmol / L. The threshold comparison result can be a comparison between the predicted value corresponding to the predicted curve and the standard threshold information, for example, a prediction that fasting blood glucose exceeds the standard by 7.2 mmol / L.

[0045] Sub-step six involves weighting the threshold comparison results using a pre-constructed clinical outcome risk model to obtain weighted risk assessment information. This pre-constructed clinical outcome risk model can be a model pre-trained on a large amount of clinical data, with threshold comparison results as input and weighted risk assessment information as output (e.g., a risk score of 92 for diabetic complications). For example, the pre-constructed clinical outcome risk model could be a Cox proportional hazards model.

[0046] Sub-step seven involves generating the dynamic risk level corresponding to the weighted risk assessment information mentioned above. In practice, this is done by first setting risk rules (0-60 low, 61-80 medium, 81+ high). Then, matching the weighted assessment information with the classification. Finally, generating the dynamic risk level.

[0047] The third step involves generating interpretable reports and intervention instructions based on the aforementioned prediction curve, dynamic risk level, and pre-built medical knowledge graph. The interpretable report can be a health report including a reasoning process. For example, it could be, "Based on the rising blood glucose trend and excessive BMI, the risk of diabetes is judged to be increased." The intervention instructions can be specific medical operation guidance. For example, "It is recommended to monitor blood glucose daily and exercise for 150 minutes per week." In practice, the cloud server 3 can generate interpretable reports and intervention instructions based on the aforementioned prediction curve, dynamic risk level, and pre-built medical knowledge graph through the following steps: Sub-step one: Based on the aforementioned prediction curves, extract the predicted values, trend information, and confidence intervals for key indicators. These key indicators can be quantitative or qualitative indicators reflecting the core state of human health and directly related to disease risk, such as fasting blood glucose, blood pressure, blood lipids, and heart rate variability. The predicted values ​​can be the future predicted values ​​of the key health indicators, for example, fasting blood glucose levels of 6.8-7.5 mmol / L for the next 7 days. The trend information can be the evolution pattern of the predicted values ​​of the key indicators, for example, blood glucose showing a "rise first, then stabilize" trend over the next week. The confidence interval information can be the reliable range of the predicted values, for example, blood glucose 7.2 mmol / L (confidence interval 6.9-7.5 mmol / L).

[0048] Sub-step two involves generating an indicator anomaly event sequence by comparing the predicted values ​​with preset anomaly thresholds. These preset anomaly thresholds are medically defined critical values ​​for health indicators, such as the diabetes warning threshold of fasting blood glucose ≥7.0 mmol / L. The indicator anomaly event sequence can be time-ordered records of indicator anomalies. In practice, firstly, based on the predicted values ​​and the anomaly threshold (≥7.0 mmol / L), anomalies are screened by comparing them point-by-point. Then, the indicator anomaly event sequence is generated.

[0049] Sub-step three involves determining the focus area information for the risk assumptions based on the aforementioned dynamic risk levels. This focus area information can be a health domain associated with high risk, such as the "diabetes and cardiovascular complications" domain corresponding to a dynamic risk level of "high". In practice, first, the dynamic risk level is "high". Then, the high-risk domain is located using a medical knowledge graph. Finally, the focus area information is determined. For example, focusing on the "diabetes and its cardiovascular complications" domain.

[0050] Sub-step four involves generating an initial evidence set based on the aforementioned focus area information and the medical knowledge graph. This initial evidence set includes risk-related medical evidence within the knowledge graph, such as evidence linking "persistently elevated blood glucose levels -> pancreatic islet function impairment." In practice, this is first done by retrieving risk-related medical evidence based on the focus area information and the medical knowledge graph. Finally, an initial evidence set is generated. For example, an initial evidence set for "persistently elevated blood glucose levels -> pancreatic islet function impairment -> diabetes."

[0051] Sub-step five involves inputting the aforementioned abnormal event sequence, the initial evidence set, and the prediction curve into a pre-built pattern discovery agent to generate potential health risk information. This pre-built pattern discovery agent can be an AI module that mines risk patterns; for example, it could be an agent that identifies the associated risk of "elevated blood sugar + abnormal blood lipids." The potential health risk information can be latent health hazards that are not explicitly presented, such as "long-term elevated blood sugar may lead to peripheral neuropathy."

[0052] Sub-step six involves inputting the aforementioned potential health risk information into a pre-built logical verification agent to perform evidence chain reasoning, thereby generating an interpretability report. This pre-built logical verification agent can be an artificial intelligence module that verifies the rationality of the evidence chain; for example, it could be an agent that verifies the logic of "abnormal blood sugar -> diabetes risk".

[0053] Sub-step seven involves determining the corresponding anomaly concentration index based on the aforementioned sequence of abnormal events. This anomaly concentration index can measure the density of anomalies; for example, the concentration index for 5 instances of elevated blood sugar within one week is 0.71. In practice, first, 5 out of 7 monitoring sessions within one week are analyzed for anomalies. Then, the anomaly concentration index is calculated as "number of anomalies / total number of anomalies," for example, 5 / 7 ≈ 0.71.

[0054] Sub-step eight: Based on the aforementioned abnormal concentration index and the preset intervention knowledge base, generate intervention instructions. The preset intervention knowledge base can be a database storing personalized intervention plans; for example, it could be a knowledge base including a "high blood sugar -> diet / exercise / monitoring" plan.

[0055] In some embodiments, the edge processing server 2 is configured to, in response to receiving the interpretability report and intervention instructions generated in the cloud, send the interpretability report and intervention instructions to the application terminal to generate a dynamic health profile. The application terminal can be a terminal device (e.g., a smartphone, tablet, or smart pillbox) that receives instructions and executes operations. The dynamic health profile can be a dynamic health view integrating real-time data. For example, the dynamic health profile can be a user health panel including real-time blood glucose levels, risk levels, and intervention instructions.

[0056] In addressing the technical challenges mentioned above, the application scenario—remote health management in a home environment with multiple terminals and unstable network conditions—often presents the following technical problems: poor command transmission reliability in complex network environments, inability to prioritize transmission based on business value, and command compatibility issues caused by terminal diversity. These issues waste system transmission and computing resources and prolong system response time. Considering the following requirements for this application scenario—high reliability, low latency, and cross-platform compatibility—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the edge processing server 2 may, in response to receiving the interpretability report and intervention instructions generated in the cloud, send the interpretability report and intervention instructions to the application terminal to generate a dynamic health profile: The first step involves receiving the interpretability report and intervention instructions generated by the cloud server, and then verifying the intervention instructions to generate verified instruction data. This verified instruction data can be any intervention instructions that have been verified as legitimate and valid. In practice, the edge server first receives the "daily blood glucose test" instruction and report from the cloud. Then, it verifies the instruction signature, permissions, and format. Finally, it generates the verified instruction data.

[0057] The second step involves adaptively converting the verified instruction data based on the application terminal's type and capability information to generate terminal-parseable instructions. These terminal-parseable instructions are formatted to match the terminal's capabilities. For example, first, the terminal is identified as an iOS system with a 6.1-inch screen. Then, the instructions are converted to an iOS-specific push notification format. Finally, instructions that the terminal can directly parse are generated.

[0058] The third step involves adding priority and timeliness tags to the aforementioned terminal-parsable instructions to generate instructions with scheduling strategy information. The priority tag can be a tag indicating the urgency of the instruction, such as "urgent" (e.g., high blood pressure warning). The timeliness tag can be a tag indicating the effective time of the instruction, such as "valid for 24 hours." The instructions with scheduling strategy information can be schedulable instructions that include both priority and timeliness.

[0059] The fourth step involves determining the corresponding instruction transmission queue based on the aforementioned priority tags and the pre-acquired current network load information. The current network load information can be data on the current network transmission pressure of the edge processing server (e.g., "network load rate 30%", "bandwidth remaining 50Mbps"). The instruction transmission queue can be a priority-ordered sequence of instruction transmissions, such as "emergency instruction queue" and "regular instruction queue". In practice, first, the network load information (load rate 30%) is obtained. Then, priority tags are matched to allocate queues to obtain the instruction transmission queues. For example, emergency instructions are transmitted first.

[0060] Fifth, the instruction containing scheduling policy information is sent to the application terminal via the aforementioned instruction transmission queue. In practice, the transmission rate can be adjusted according to the instruction transmission queue. Then, the instruction containing scheduling policy information is sent to the application terminal.

[0061] The sixth step is to send a profile generation trigger signal to the aforementioned application terminal to drive the application terminal to generate a dynamic health profile. This profile generation trigger signal can be a control signal that drives the application terminal to generate the profile. In practice, first, the instruction transmission is confirmed to be complete; then, a trigger signal is sent to the application terminal to drive it to generate a dynamic health profile.

[0062] The above-described operational steps, as an inventive point of this disclosure, solve the aforementioned technical problems of "poor reliability of instruction transmission in complex network environments, inability to differentiate transmission priorities based on business value, and instruction compatibility issues caused by terminal diversity, resulting in wasted system transmission and computing resources and prolonged system response time." The reasons for these technical problems are as follows: traditional systems employ an indiscriminate, best-effort data transmission method, failing to consider business priorities and real-time network status, and lacking adaptability to heterogeneous terminals. This invention, by introducing instruction verification, intelligent scheduling, and adaptive conversion mechanisms at the edge layer, achieves low-latency, high-reliability transmission and precise delivery of critical intervention instructions, saving potential medical risk management costs caused by instruction transmission failures or delays, optimizing the utilization efficiency of network bandwidth resources, reducing system response time, and saving computing resources.

[0063] In some embodiments, the application terminal 3 is configured to control home medical devices to perform corresponding personalized operations based on the aforementioned dynamic health profile. These home medical devices can be smart devices used in a home environment capable of performing specific medical functions. For example, they may include: a smart insulin pump, a smart pillbox, or a remote electrocardiogram monitor. The personalized operations can be device control based on individual needs, such as adjusting the insulin infusion rate according to real-time blood glucose levels.

[0064] In addressing the technical challenges mentioned above, the application scenario of precision management of chronic diseases at home often presents the following issues: mismatched device control parameters, insecure transmission of medical device control commands, and lack of feedback loops in execution status, resulting in wasted system transmission resources and time costs. Considering the following requirements for this application scenario—security, closed-loop control, and data continuity—we have decided to adopt the following solution: In some optional implementations of certain embodiments, the application terminal 3 can control the home medical device to perform corresponding personalized operations based on the dynamic health profile described above through the following steps: The first step is to generate a device parameter control set based on the intervention instructions derived from the aforementioned dynamic health profile. This device parameter control set can be a set of parameters that drive the operation of home medical devices. In practice, specific parameter values ​​can be determined through intervention instructions to generate the device parameter control set.

[0065] The second step involves matching the aforementioned device parameter control set with the aforementioned home medical devices to obtain the target device identifier. This target device identifier can be a unique identifier for the home medical device, such as the device ID "01" for an insulin pump. In practice, this can be achieved by scanning registered home medical devices on the home network to match the corresponding target device identifier.

[0066] The third step is to determine the corresponding device status confirmation signal based on the target device identifier mentioned above. This device status confirmation signal can be feedback information about the device status. For example, {"Online": true, "Ready": true, Battery: 85%}. In practice, first, a status query command is sent to the home medical device. Then, the device status feedback information returned by the home medical device is received.

[0067] The fourth step involves generating a device control command queue based on the aforementioned device status confirmation signal and device parameter control set. This device control command queue can be an ordered sequence of device commands. In practice, firstly, a command queue containing parameter settings and security checks is generated based on the device status confirmation signal and the aforementioned device parameter control set, serving as the device control command queue.

[0068] The fifth step involves sending the aforementioned device control command queue to the aforementioned home medical device via a pre-built secure communication link, controlling the home medical device to execute corresponding personalized operations, and generating corresponding execution status information for the home medical device. The pre-built secure communication link can be a secure device communication channel, such as a Bluetooth encrypted connection based on TLS 1.3. The execution status information can be operational feedback data after the home medical device's operation. In practice, firstly, the application terminal initiates the pre-built secure communication link (e.g., a TLS-encrypted secure communication link) to verify the identity of the home medical device (e.g., a smart blood pressure monitor for hypertensive patients). Then, control commands (e.g., "8 AM monitoring + systolic blood pressure threshold 140 mmHg") are sent in queues via the secure communication link. Upon receiving the commands, the device executes personalized operations and generates execution status information.

[0069] Step 6: Update the dynamic health profile based on the aforementioned execution status information to generate an updated dynamic health profile. This updated dynamic health profile can be a health view incorporating the device's execution status. For example, it could be a panel with added blood pressure monitoring results and device operation records. In practice, first, the execution status information of the home medical device is received. Then, the execution status information is incorporated into the dynamic health profile. Finally, the updated dynamic health profile is generated.

[0070] Step 7: Store the execution status information and the updated dynamic health profile to the corresponding health record. The health record can be a structured database storing user health data. In practice, first, extract the execution status information and the updated dynamic health profile. Then, locate the cloud-based health record by associating it with the user ID corresponding to the application terminal. Finally, store the data in the record.

[0071] The above-described operational steps, as an inventive point of this disclosure, solve the aforementioned technical problems of "mismatched device control parameters, insecure transmission of medical device control commands, and lack of feedback loops in execution status, resulting in wasted system transmission resources and time costs." The reasons for these technical problems are as follows: traditional control methods lack device status confirmation mechanisms, secure communication guarantees, and execution result feedback links, making it impossible to form a reliable closed-loop record. This invention establishes a full-link control mechanism of "command parsing -> device matching -> status confirmation -> secure transmission -> execution feedback -> profile update -> file storage," achieving reliable execution and full-process traceability of personalized interventions. This saves on medical risk management costs caused by control failures or operational chaos, conserves system transmission resources, and improves system control efficiency.

[0072] In addressing the technical problems mentioned above by adopting technical solutions, the application scenario—precise management of chronic diseases at home—often involves complex command control of various types of home medical devices (e.g., insulin pumps and continuous glucose monitors). This often presents the following technical issues: multiple command conflicts, high execution failure rates, and lack of security controls. These issues lead to low control execution efficiency of the home medical device control system, resulting in excessively long system response times, wasting significant time and control costs, and ultimately, wasting medical resources. Considering the following requirements for this application scenario—reliability, security, and real-time performance—we have decided to adopt the following solution: Optionally, the application terminal 3 can generate a device control command queue based on the device status confirmation signal and the device parameter control set through the following steps: The first step, based on the aforementioned device parameter control set, is to generate operation type information, target parameter value information, and execution priority information. The operation type information can be the specific operation category of the instruction, such as "adjust infusion rate" or "start monitoring mode." The target parameter value information can be the specific value the instruction aims to achieve, such as "set the target blood glucose value to 6.5 mmol / L." The execution priority information can be an indicator of the urgency of the instruction execution.

[0073] The second step involves determining the current availability and readiness status of the home medical device based on the aforementioned device status confirmation signal. The current availability information can be the device's current availability status (e.g., online). The readiness status information can be the device's preparation status for executing instructions. In practice, the application terminal then determines the device's current availability information (e.g., "online") and readiness status information (e.g., "idle") based on the device status confirmation signal.

[0074] The third step involves dynamically sorting at least one pending operation based on the aforementioned execution priority information and readiness status information to generate an initial instruction sequence. This at least one pending operation can be a set of one or more instructions that need to be queued. The initial instruction sequence can be a list of operations initially sorted based on priority and status. In practice, the initial instruction sequence can be generated by dynamically sorting at least one pending operation based on execution priority information and readiness status information. For example, the high-priority "adjust base rate" can be prioritized before the more common "read device logs".

[0075] The fourth step involves adding timing dependency tags and timeout retry policy information to each initial instruction in the initial instruction sequence to generate a fault-tolerant instruction sequence. The timing dependency tags can be metadata identifying the temporal order between instructions. For example, the timing dependency tag could be that "adjusting the basal rate" must be executed after "reading blood glucose" is successfully completed. The timeout retry policy information can define the waiting time and retry mechanism after instruction execution failure. For example, the timeout retry policy could be set to "timeout 10 seconds, maximum retries 3 times". In practice, a fault-tolerant instruction sequence can be generated by adding timing dependency tags and timeout retry policy information to each instruction in the initial instruction sequence.

[0076] The fifth step involves matching the aforementioned fault-tolerant instruction sequence with a preset safety operation rule base to generate a safety instruction set. This preset safety operation rule base can be a database storing device safety operation specifications, such as "maximum single insulin infusion limit rules." The safety instruction set can be generated in practice by first determining whether each instruction in the fault-tolerant instruction sequence conforms to safety rules, then verifying that the parameters are within allowable ranges, and finally generating an instruction set that passes the safety check as the safety instruction set.

[0077] The sixth step involves encapsulating the aforementioned security instruction set into a frame format corresponding to the communication protocol of the home medical device to generate a device control instruction queue. In practice, this is done first by converting the security instruction set into a device-specific protocol format. Then, a frame header and checksum are added for encapsulation. Finally, the device control instruction queue is generated.

[0078] The above-described operational steps, combined with "controlling home medical devices to perform corresponding personalized operations," constitute an inventive point of this disclosure. This addresses the technical problems mentioned in the background section: "multiple instruction conflicts, high execution failure rates, and lack of security control lead to low control execution efficiency in home medical device control systems, resulting in excessively long system control response times, wasting significant time and control costs, and consequently, wasting medical resources." The causes of these technical problems are as follows: instructions are not sorted according to priority and device status; there is a lack of fault-tolerant design such as timeout retries; instruction formats are not adapted to device protocols; and no security rule verification mechanism is introduced. This invention, through a six-step instruction queue generation process of "parameter parsing -> status verification -> dynamic sorting -> fault-tolerant embedding -> security verification -> protocol encapsulation," achieves conflict-free scheduling, low-failure-rate execution, and security control of home medical device instructions in home chronic disease management. This improves control execution efficiency and response speed, saves time costs associated with instruction retransmission and fault diagnosis, reduces control costs for repairing device malfunctions, and minimizes the waste of medical resources.

[0079] The various embodiments of this disclosure have the following beneficial effects: Through the cloud-edge-device collaborative home medical device control system of some embodiments of this disclosure, the system resources of the home medical device control system are optimized, reducing the system's control response time. Specifically, the reasons for unreasonable system resource configuration and excessively long control response time in home medical device control systems are: traditional home medical device control systems adopt a centralized processing architecture, resulting in excessive cloud computing load and high data transmission latency; at the same time, the lack of edge-side preprocessing and privacy computing capabilities causes raw sensitive data to be transmitted over long distances over the network, increasing communication overhead and affecting control real-time performance. Based on this, the cloud-edge-device collaborative home medical device control system of some embodiments of this disclosure includes an acquisition terminal, an edge processing server, a cloud server, and an application terminal. First, the acquisition terminal is configured to acquire multimodal health data. This achieves comprehensive collection of multimodal health data of the target user, providing a complete data foundation for health analysis and solving the problem of inaccurate assessment from a single data source. Then, the edge processing server is configured to preprocess the multimodal health data to generate edge health features. By preprocessing data on the edge processing server, data transmission volume is reduced, user privacy is protected, and standardized input is provided for cloud analysis. Then, the cloud server is configured to integrate the edge health features with pre-acquired clinical data to generate a dynamic multimodal dataset. Deeply fusing edge health features with pre-acquired clinical data constructs a dataset comprehensively reflecting health status, laying the foundation for precise analysis. Based on the health feature vectors corresponding to the dynamic multimodal dataset, corresponding prediction curves and dynamic risk levels are generated. The generated prediction curves are used to predict the development trend of health indicators, achieving a leap from static assessment to dynamic prediction and identifying health risks in advance. Based on the prediction curves, dynamic risk levels, and a pre-constructed medical knowledge graph, interpretable reports and intervention instructions are generated. The pre-constructed medical knowledge graph is used to verify the medical rationality of decisions, outputting credible solutions with both operational suggestions and evidence support. Next, the edge processing server is configured to, in response to receiving the interpretable reports and intervention instructions generated in the cloud, send them to the application terminal to generate a dynamic health profile. This process transforms professional medical data into intuitive and visual health reports, making it easier for doctors and patients to understand their current health status and future risks. Finally, the application terminal is configured to control home medical devices to perform corresponding personalized operations based on the dynamic health profile. This achieves a closed loop from multimodal health data analysis to home medical device control, enabling home medical devices to automatically adjust control schemes based on real-time health conditions, significantly reducing system control response time.

[0080] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0083] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A home medical device control system based on cloud-edge-device collaboration, wherein, The home medical device control system includes an acquisition terminal, an edge processing server, a cloud server, and an application terminal, wherein: The acquisition terminal is configured to acquire multimodal health data; The edge processing server is configured to preprocess the multimodal health data to generate edge health features; The cloud server is configured as follows: The marginal health features are integrated with pre-acquired clinical data to generate a dynamic multimodal dataset; Based on the health feature vectors corresponding to the dynamic multimodal dataset, generate corresponding prediction curves and dynamic risk levels; Based on the prediction curve, the dynamic risk level, and the pre-constructed medical knowledge graph, interpretable reports and intervention instructions are generated. The edge processing server is also configured to, in response to receiving the interpretable report and intervention command generated by the cloud server, perform downlink command processing and profile generation triggering processing, including: In response to receiving the interpretability report and intervention instructions generated by the cloud server, the intervention instructions are verified to generate verified instruction data; Based on the type and capability information of the application terminal, the verified instruction data is adaptively transformed to generate terminal-parseable instructions; Priority and timeliness tags are added to the terminal-parseable instructions to generate instructions containing scheduling strategy information; Based on the priority label and the pre-acquired current network load information, determine the corresponding instruction transmission queue; The instruction containing scheduling policy information is sent to the application terminal through the instruction transmission queue. Send a profile generation trigger signal to the application terminal to drive the application terminal to generate a dynamic health profile based on the instruction containing the scheduling strategy information; The application terminal is configured to generate a device parameter control set based on the intervention instructions in the dynamic health profile, generate a device control instruction queue based on the device parameter control set and the device status confirmation signal of the home medical device, and send the device control instruction queue to the home medical device through a pre-built secure communication link to control the home medical device to perform corresponding personalized operations.

2. The system according to claim 1, wherein, The edge processing server is configured to: In response to the edge processing server receiving the multimodal health data, the multimodal health data is cleaned and outlier correction is performed to generate a regular time-series dataset; Text annotation is performed on the unstructured text in the regularized time-series dataset to generate standardized text data; Align the numerical data and the standardized text data in the regularized time series dataset to generate a spatiotemporally aligned dataset; Differential privacy processing is performed on sensitive information in the spatiotemporal aligned dataset to generate a desensitized local feature set; Short-term trend statistics are extracted from the desensitized local feature set and encapsulated as initial edge health features; Add data quality labels to the initial edge health features to serve as edge health features.

3. The system according to claim 1, wherein, The cloud server is configured as follows: The marginal health features are spatiotemporally aligned with the clinical data to obtain an aligned multi-source dataset. Construct a corresponding panoramic timeline based on the aligned multi-source dataset; Missing values ​​in the panoramic timeline are filled in to obtain a continuous health record sequence; Primary statistical features are generated by determining the window statistics of the continuous health record sequence; Based on the aforementioned primary statistical features, a time-series interaction term is constructed to obtain cross-modal features; Based on the cross-modal features and the medical knowledge graph, semantically enhanced features are generated. The primary statistical features, the cross-modal features, and the semantic enhancement features are integrated into a dynamic multimodal dataset.

4. The system according to claim 1, wherein, The cloud server is configured as follows: Text sequence data, image data, and time-series signal data are separated from the dynamic multimodal dataset; The text sequence data is encoded using a pre-trained medical language model to obtain a text feature vector; The image data is used to extract features using a deep neural network to obtain an image feature vector; The time-series signal data is encoded using a recurrent neural network to obtain a time-series feature vector; The text feature vector, the image feature vector, and the temporal feature vector are projected onto a unified dimensional space to generate an aligned multimodal feature set; The aligned multimodal feature set is input into a pre-trained fusion network to generate preliminary fusion features; The preliminary fusion features are normalized and linearly projected to generate a health feature vector.

5. The system according to claim 1, wherein, The cloud server is configured as follows: By constructing the time-series sequence data corresponding to the health feature vector, a corresponding historical state sequence is generated; The historical state sequence is time-encoded to generate a time-aware sequence containing absolute position and relative time interval information; The time-aware sequence is encoded to generate a deep temporal representation with dependencies; Determine the prediction curve corresponding to the depth time series representation; A threshold comparison result is generated by comparing the predicted curve with pre-acquired standard threshold information; The threshold comparison results are weighted using a pre-constructed clinical outcome risk model to obtain weighted risk assessment information; Generate the dynamic risk level corresponding to the weighted risk assessment information.

6. The system according to claim 1, wherein, The cloud server is configured as follows: Based on the prediction curve, the predicted value information, trend information and confidence interval information of key indicators are extracted; By comparing the predicted value information with a preset abnormal standard threshold, an indicator abnormal event sequence is generated; Based on the dynamic risk level, determine the key areas of information for risk assumptions; Based on the focal area information and the medical knowledge graph, an initial evidence set is generated; The abnormal event sequence of the indicators, the initial evidence set, and the prediction curve are input into a pre-constructed pattern discovery agent to generate potential health risk information. The potential health risk information is input into a pre-built logical verification agent to perform chain of evidence reasoning in order to generate an interpretability report; The corresponding abnormal concentration index is determined based on the abnormal event sequence of the aforementioned indicators. Based on the abnormal concentration index and the preset intervention knowledge base, intervention instructions are generated.

Images