Dual-mode intelligent connection switching method for medical monitoring devices

Abstract

The application discloses a kind of dual-mode intelligent connection switching methods of medical monitoring equipment, including medical detection equipment built-in dual-mode communication module, based on dual-mode communication module access to medical platform;Dual-mode communication module provides communication mode one and communication mode two, access medical platform by one of communication mode one and communication mode two.The application has the advantages that: using dual-mode method carries out the intelligent connection and switching of medical detection equipment, effectively guarantee the reliability and stability of communication, reduce the data transmission and interactive terminal caused by communication anomaly, improve the stability of remote medical treatment, remote diagnosis.

Description

Technical Field

[0001] This invention relates to the field of medical Internet of Things, and in particular to a dual-mode intelligent connection switching method for medical monitoring devices. Background Technology

[0002] With the development of IoT technology, healthcare has shifted from traditional face-to-face diagnosis and treatment to remote diagnosis and treatment, thus realizing medical IoT technology. In medical IoT technology, dedicated medical monitoring equipment monitors users' physical indicators and other data in real time, and transmits the collected data to a cloud platform via the IoT. The cloud platform can then use big data models or hospital doctors to evaluate the user's physical parameters, thereby achieving remote diagnosis. For example, patent application number 202111058561.3 describes an automatic network connection method and device for medical devices in a medical IoT scenario. This patent enhances the efficiency of the initial connection of medical devices to the hospital's IoT network and enables automatic, rapid, and seamless connection of medical devices to the hospital's IoT network after the initial connection.

[0003] However, this patent still uses a single-mode approach to access the cloud platform for communication. Reliable data transmission is crucial for healthcare, so the single-mode sensing method is prone to data transmission interruptions and cannot guarantee the reliability of the transmission. Summary of the Invention

[0004] The purpose of this invention is to overcome the shortcomings of the prior art and provide a dual-mode intelligent connection switching method for medical monitoring devices. This method uses a dual-mode approach to intelligently connect and switch medical monitoring devices, effectively ensuring the reliability and stability of communication, reducing data transmission and interaction terminal failures caused by communication anomalies, and improving the stability of telemedicine and remote diagnosis.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0006] A dual-mode intelligent connection switching method for medical monitoring equipment includes a built-in dual-mode communication module in the medical monitoring equipment, and access to a medical platform based on the dual-mode communication module; the dual-mode communication module provides communication mode one and communication mode two, and access to the medical platform is achieved through one of the communication modes of communication mode one and communication mode two.

[0007] The dual-mode communication module provides Wi-Fi mode and AP mode and monitors the current communication status in real time to switch between the two.

[0008] After the dual-mode communication module is activated, it connects to the medical platform using either the current preset mode or the default mode. Then, it uses an intelligent switching strategy to monitor the status information of the current communication mode in real time and switches between the two communication modes based on the monitored status information.

[0009] The intelligent handover strategy includes any one or a combination of the following: an adaptive handover method based on signal quality, a scenario-aware handover method based on application scenarios, and a historical learning handover method based on machine learning. The intelligent handover strategy is used to monitor and switch communication modes in real time.

[0010] Adaptive handover methods based on signal quality include:

[0011] Collect network metrics data, including signal strength, packet loss rate, latency, bandwidth, stability, and connection hold time;

[0012] Scores for Mode 1 and Mode 2 are calculated based on the collected network indicator data;

[0013] Whether to switch network modes is determined based on the scores of Mode 1 and Mode 2.

[0014] At each set period, a quality assessment is performed on the current network mode and the alternative network modes to obtain the scores of communication mode one and communication mode two. If the score of the alternative network mode is greater than the sum of the score of the current network mode and the buffer threshold, it is determined to switch the network mode and switch to another communication mode to connect to the medical platform.

[0015] The scenario-aware switching method based on application scenarios includes dynamically collecting device status indicators, identifying the current scenario through rule-based judgment, and finally returning the scenario name. The corresponding network communication mode is then selected based on the scenario name. Priority is given to ensuring uninterrupted data transmission for medical monitoring when collecting device status indicators.

[0016] The collected device status indicators include initial power-on status, network stability score, device movement range, user behavior analysis, and time elapsed since the last mode configuration.

[0017] The current scenario is determined by classifying scenarios based on preset rules.

[0018] The historical learning switching method based on machine learning includes building a machine learning model, training the built machine learning model, predicting the current optimal network mode through the trained machine learning model, and completing the switching of the network model; the machine learning model predicts the optimal network mode and its confidence level based on real-time features by obtaining the current device and network status output, and performs switching control based on the confidence level and the optimal network mode.

[0019] The machine learning mode adopts an online learning approach to achieve dynamic iteration and optimization of the model. The device state characteristics before each switch and the switch result are used as new training data. When the new training data accumulates to a set threshold, the machine learning model is retrained and the model parameters are updated using the accumulated training data.

[0020] The advantages of this invention are: it adopts a dual-mode approach for intelligent connection and switching of medical testing equipment, which effectively ensures the reliability and stability of communication, reduces data transmission and interaction terminal failures caused by communication anomalies, and improves the stability of telemedicine and remote diagnosis. Attached Figure Description

[0021] The following is a brief explanation of the contents of each of the accompanying drawings and the markings in the drawings:

[0022] Figure 1 This is a flowchart illustrating the overall process of dual-mode intelligent switching in this invention.

[0023] Figure 2 This is a flowchart of the intelligent mode switching decision algorithm of the present invention. Detailed Implementation

[0024] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and the description of the preferred embodiments.

[0025] Existing medical monitoring equipment single-mode interventional medical platforms suffer from network instability. To address the issue of medical monitoring equipment accessing medical platforms, this application designs a dual-mode communication mode to achieve network access stability and reliability. Simultaneously, it can automatically switch modes based on the real-time communication status data of the medical and health equipment to dynamically adjust the communication mode and meet the requirements of automatic switching to match network stability.

[0026] like Figure 1 , 2 As shown in this embodiment, a dual-mode intelligent connection switching method for a medical monitoring device includes a built-in dual-mode communication module in the medical monitoring device, and access to a medical platform based on the dual-mode communication module; the dual-mode communication module provides communication mode one and communication mode two, and accesses the medical platform through one of the communication modes of communication mode one and communication mode two.

[0027] The dual-mode communication module provides both Wi-Fi and AP modes and monitors the current communication status in real time, switching between the two. Wi-Fi mode can be communication mode one, and AP mode can be communication mode two; the two modes can be switched freely, thus solving the communication stability problem associated with traditional single-mode communication. Through dual-mode communication, the module switches between modes based on current communication needs and status.

[0028] In this embodiment, after the dual-mode communication module starts up, it connects to the medical platform using either the current preset mode or the default mode. Then, an intelligent switching strategy monitors the status information of the current communication mode in real time and switches between the two communication modes based on the monitored status information. After the medical monitoring device starts up, it connects to the medical platform using either the default or preset communication mode. The default communication mode is pre-configured to ensure immediate connection to the medical platform after device startup. Mode switching can only be achieved after connection to the medical platform; therefore, a default mode needs to be pre-set. The default mode can be either Wi-Fi mode or AP mode. After connecting to the medical platform via the default mode, the communication status data is monitored in real time, and then the intelligent switching strategy switches between Wi-Fi mode and AP mode.

[0029] In this embodiment, the intelligent switching strategy includes an adaptive switching method based on signal quality, a context-aware switching method based on application scenarios, and / or a historical learning switching method based on machine learning. Based on the intelligent switching strategy, the communication mode is monitored and switched in real time. This embodiment provides three methods for switching communication modes, thereby completing the intelligent switching of modes.

[0030] In this embodiment, the adaptive switching method based on signal quality includes:

[0031] Collect network metrics data, including signal strength, packet loss rate, latency, bandwidth, stability, and connection hold time;

[0032] Scores for Mode 1 and Mode 2 are calculated based on the collected network indicator data;

[0033] Whether to switch network modes is determined based on the scores of Mode 1 and Mode 2.

[0034] At any given set interval, a quality assessment is performed on the current network mode and the alternative network modes to obtain scores for Communication Mode 1 and Communication Mode 2. If the score of the alternative network mode is greater than the sum of the score of the current network mode and the buffer threshold, it is determined that the network mode needs to be switched, and the connection to the medical platform is switched to another communication mode. The main purpose of setting the buffer threshold is to avoid repeated and frequent switching jitter. Therefore, a threshold is set for Wi-Fi mode and AP mode, one of which is in operation and the other is in a backup state. When the score of the communication mode in the backup state is greater than the score of the current network mode and greater than the sum of the score of the current network mode and the buffer threshold, it is determined that a switch is required, and the communication mode is switched to another alternative communication mode.

[0035] In this embodiment, adaptive mode switching based on signal quality is used to realize intelligent switching of device network modes. The goal is to automatically switch between different modes according to real-time network quality, so as to ensure the stability and reliability of service communication.

[0036] This method is a "decision basis generator" for mode switching. It takes a network mode to be evaluated as input and outputs a comprehensive quality score for that mode. The execution process consists of two steps:

[0037] 1. Collect network metrics:

[0038] Six core network performance metrics were collected as the raw data source for the quality score:

[0039] RSSI: Signal strength (reflects the strength of the network signal; the higher the value, the better the signal).

[0040] packetLoss: Packet loss rate (the proportion of data packets lost during data transmission; the lower the proportion, the more reliable the network).

[0041] latency: delay (the time difference between sending and receiving data; the lower the latency, the faster the network response).

[0042] bandwidth: (the data transmission capacity of a network; the larger the bandwidth, the faster the transmission speed).

[0043] stability: stability (the fluctuation range of network metrics; the smaller the fluctuation, the better the stability).

[0044] duration: Connection hold time (the duration for which the current mode has a stable connection; the longer the hold time, the more reliable the connection).

[0045] 2. Calculate the overall score:

[0046] The collected six raw indicators are fed into the internal comprehensive scoring model. The model converts the multi-dimensional indicators into a unified percentage score and returns the score as the basis for whether to switch modes.

[0047] The scoring model is designed as follows:

[0048] This model takes into account the core transmission requirements of low packet loss, low latency, and high reliability of medical data, and also considers the need to avoid the insufficient scenario adaptability of existing equal-weight / fixed-weight models. It adopts a fusion algorithm of medical business-oriented differentiated weight allocation + nonlinear normalization + index cross-correction, which transforms six heterogeneous indicators, namely signal strength, packet loss rate, latency, bandwidth, stability, and connection hold time, into a unified percentage score of 0-100.

[0049] I. Definition and Quantification Standards of 6 Indicators

[0050] First, the six original indicators were uniformly quantified and defined, clarifying the optimal value, inferior value, and failure threshold of the indicators (the failure threshold is when the indicator reaches the value, the mode is directly judged as unusable and the score is 0), which provides a basis for subsequent normalization. All quantitative standards are in line with the actual communication scenarios of medical IoT devices.

[0051]

[0052] Among them, stability S is the normalized result of the volatility coefficient of the network indicators (R / L / T / B). The volatility coefficient = indicator standard deviation / indicator mean. The smaller the volatility coefficient, the higher the S score.

[0053] II. Core Algorithm of the Model

[0054] The comprehensive score calculation of this model consists of 4 core steps: nonlinear normalization → basic weight allocation → adaptive weight correction of connection state → stability cross correction, and finally outputs a comprehensive quality score of 0-100.

[0055] Step 1: Nonlinear normalization of the 6 indicators (Xi′)

[0056] The raw values ​​of each indicator are mapped to a standard range of 0-1. Differentiated nonlinear normalization formulas are designed for "higher values ​​are better" (positive indicators) and "lower values ​​are better" (negative indicators). The core indicators (packet loss rate L, latency T) employ exponentially penalized normalization to amplify the score decay during degradation, aligning with the hard constraints of medical operations. The six indicators can be divided into positive and negative indicators. Positive indicators include signal strength R, bandwidth B, stability S, and connection hold time D, while negative indicators are packet loss rate L and latency T. Different normalization schemes are used for positive and negative indicators. Details are as follows:

[0057] (1) Normalization of positive indicators (signal strength R, bandwidth B, stability S, connection hold time D)

[0058] A saturated nonlinear normalization method is adopted, and the score is saturated to 1 after the index reaches the optimal value to avoid overweighting; the score decays rapidly when the index approaches the failure threshold.

[0059]

[0060] Where: k=3 (non-linear coefficient, attenuation rate adapted to medical scenarios); Xi(opt) = optimal value, Xi(bad) = inferior value, Xi(invalid) = failure threshold. These are the normalized index parameters.

[0061] (2) Normalization of negative index penalty (packet loss rate L, delay T)

[0062] An exponentially penalized normalization method is employed, where the score decreases exponentially after an indicator exceeds a poor value. This reinforces the stringent requirements for low packet loss and low latency in medical data, distinguishing it from the linear normalization methods used in existing patents. The negative indicator normalization process is as follows:

[0063]

[0064] Where: m=5 (penalty coefficient, amplifying the impact of core indicator degradation); Xi(opt)=optimal value, Xi(bad)=bad value, Xi(invalid)=failure threshold. This is the value after normalizing the negative index. The original measured value of the indicator.

[0065] Step 2: Basic weight allocation (Wi) oriented towards healthcare business

[0066] Based on the transmission requirements of medical monitoring data, a non-equal weighted basic weight is designed, with core indicators (packet loss rate, latency) accounting for over 50% and bandwidth indicators accounting for the lowest proportion (fitting the characteristics of small data packet transmission in medical settings). This differs from existing patent designs that use average weights or fixed high-bandwidth weights, ensuring that the basic weight meets the requirements. Each of the six indicators has a different basic weight. These basic weights are pre-assigned and designed based on their relative importance during communication. The basic weights can be fine-tuned according to actual circumstances. One example of basic weight allocation in this embodiment is as follows:

[0067]

[0068] Step 3: Adaptive weight adjustment based on connection state ( )

[0069] Using the normalized value D′ of the connection hold time as a state correction coefficient, the basic weights are dynamically adjusted. The longer the connection hold time in the current mode (the closer D′ is to 1), the higher the weight of the core indicator (L′ / T′) and the lower the weight of the non-core indicator. The shorter the connection hold time (the closer D′ is to 0), the more the weight of signal strength and stability is appropriately increased to adapt to the scenario of "prioritizing the basic quality of the link when the connection is unstable". This part is the core innovation.

[0070] (1) Weighting correction coefficient α

[0071] α = D′ (0 ≤ α ≤ 1)

[0072] α increases linearly with increasing connection hold time, reflecting the connection stability of the current mode. 'a' is a weighting correction coefficient, which is positively correlated with the normalized value of connection hold time, D′.

[0073] (2) Weighting adjustment of core indicators (L′ / T′)

[0074] Packet loss rate weight Delay weight ;

[0075] (3) Weight adjustment of non-core indicators (R′ / S′ / B′)

[0076] Signal strength weight Stability weights Bandwidth weight .

[0077] (4) Weight normalization

[0078] The revised weights are then renormalized to ensure... To ensure quantitative consistency in scoring:

[0079] ;

[0080] Step 4: Stability Cross-correction and Overall Score Calculation (Score)

[0081] The stability normalization value S′ is used as the global correction coefficient to perform a second cross correction on the superposition result of “indicator normalization value × corrected weight”, so as to avoid the pseudo-high quality state of excellent individual indicators but large overall network fluctuations, which is different from the independent indicator superposition scoring of existing patents.

[0082] The final comprehensive scoring formula is:

[0083]

[0084] in: The corrected weighted score is calculated as (0-1); multiply by S′ to achieve stability cross-correction (0-1); multiply by 100 to map the final result to a percentage score of 0-100. The corrected weights are those that have been normalized. A normalized indicator;

[0085] III. Correlation Rules between Scoring Results and Mode Switching

[0086] 1. Basic availability threshold: If the score is ≥60, the mode is determined to be "communication available"; if the score is <60, it is determined to be "communication unavailable", and the alternative mode switching is triggered directly.

[0087] 2. Switching basic threshold: A score of ≥75 points indicates that the mode is considered a "high-quality communication state" and meets the basic conditions for being a switching target (consistent with the document requirements).

[0088] 3. Hysteresis switching rule: If the overall score of the alternative mode is greater than the overall score of the current mode + 10 points (buffer threshold), and the score of the alternative mode is ≥75 points, the mode switching will be triggered (consistent with the document requirements).

[0089] 4. Forced switching rules: If the current mode score is less than 60 points (unavailable), the switch will be triggered directly regardless of the score of the alternative mode (to ensure uninterrupted medical data transmission).

[0090] Compared with similar scoring models in existing patents, the core innovations of this patent are reflected in the following three differentiated designs:

[0091] 1. Exponential penalty normalization of core indicators: Exponential penalty normalization is used for packet loss rate and latency, instead of the linear normalization of existing patents. This fits the hard constraints of medical data on low packet loss and low latency, and amplifies the impact of the degradation of core indicators.

[0092] 2. Adaptive weight adjustment for connection status: The weight of each indicator is dynamically adjusted based on the connection hold time, rather than the fixed weight allocation of existing patents, to adapt to the needs of different connection status scenarios.

[0093] 3. Global cross-correction of stability: Stability is used as a global correction coefficient to make a second correction to the comprehensive score, instead of the weighted sum of independent indicators in existing patents, thus avoiding misjudgment of "pseudo-high-quality" network states.

[0094] 3. Network switching conditions:

[0095] The system automatically performs a quality assessment of the current or alternative network modes every 30 seconds to avoid performance degradation caused by real-time assessment. Switching is only possible when the overall quality score of a network mode reaches 75%. To prevent "frequent switching jitter" (e.g., if mode A scores 75 and mode B scores 74, switching will occur repeatedly without hysteresis), a 10% buffer is reserved during actual switching.

[0096] In this embodiment, the scenario-aware switching method based on application scenarios includes dynamically collecting device status indicators, identifying the current scenario through rule-based judgment, and finally returning the scenario name, and selecting the corresponding network communication mode according to the scenario name.

[0097] The collected device status indicators include initial power-on status, network stability score, device movement range, user behavior analysis, and time elapsed since the last mode configuration.

[0098] The current scenario is determined by classifying scenarios based on preset rules.

[0099] The scenario-aware switching function, based on application scenarios, automatically identifies the current operating scenario of the device and matches the corresponding network mode switching strategy. This addresses the pain point that "a single switching rule cannot adapt to different business scenarios," making network mode switching more aligned with actual usage needs. Through preset scenario templates and dynamic scenario recognition, the network mode switching strategy is adaptively adjusted. Detailed descriptions of the four preset scenarios are as follows:

[0100]

[0101] The steps for switching between scenario modes include:

[0102] Step 1: Collect 5 core scenario recognition indicators, gather device and environmental status data, and form an indicator set. The meanings of the indicators are as follows:

[0103] isFirstBoot: Is this the first time the device is powered on?

[0104] networkStability: Network stability score (the higher the score, the more stable the network).

[0105] deviceMovement: The extent of device movement (the higher the value, the more intense the movement);

[0106] userInteraction: User behavior analysis (focusing on determining whether the user is in configuration mode);

[0107] timeSinceLastConfig: The time elapsed since the last configuration (in seconds).

[0108] Step 2: Rule-based scenario classification (priority from high to low)

[0109] By using multi-condition branching judgments and following the principle of "precise matching first, default as a fallback," the current scenario is determined. The judgment logic is as follows:

[0110] 1. If it is the first time the device is powered on or less than 300 seconds (5 minutes) since the last configuration, then the INITIAL_DEPLOYMENT initial deployment scenario will be matched.

[0111] 2. If the above conditions are not met, and the network stability is >90 and the device has not moved, then the STABLE_ENVIRONMENT stable environment scenario is matched.

[0112] 3. If the above conditions are not met, and the device movement amplitude is greater than 0.3, then the MOBILE_SCENARIO mobile scenario is matched.

[0113] 4. If the above conditions are not met, and the user is in configuration mode, then the CONFIGURATION_MODE configuration mode scenario will be matched.

[0114] 5. If none of the conditions are met, the default setting will be the STABLE_ENVIRONMENT stable environment scenario.

[0115] Switching control is performed based on the communication mode corresponding to each scenario, thereby completing the switching control according to the scenario mode.

[0116] In this embodiment, the historical learning-based switching method based on machine learning includes building a machine learning model, training the built machine learning model, predicting the current optimal network mode using the trained machine learning model, and completing the network model switching. The machine learning model predicts the optimal network mode and its confidence level based on real-time features obtained from the current device and network status output, and performs switching control based on the confidence level and the optimal network mode. The machine learning model adopts an online learning approach to achieve dynamic iteration and optimization of the model. The device status features before each switch and the switch result are used as new training data. When the new training data accumulates to a set threshold, the machine learning model is retrained and the model parameters are updated using the accumulated training data.

[0117] By employing a closed-loop logic of "feature extraction - model training - intelligent prediction - online learning," and leveraging historical data and real-time status to autonomously learn the optimal switching strategy, this addresses the pain point of traditional rule-based switching failing to adapt to complex and ever-changing scenarios, achieving more accurate and adaptive network mode switching. By mining the correlation patterns among multi-dimensional features such as time, network, and device, it autonomously generates switching strategies suitable for network mode switching needs in complex and dynamic environments.

[0118] Switching between machine learning modes involves the following steps:

[0119] I. Model Training

[0120] Model training is the "training entry point" for machine learning models. It takes historical training data as input and outputs a prediction model that has been trained and has passed evaluation.

[0121] I. Model Selection

[0122] Since medical monitoring devices are mostly embedded low-computing-power hardware (such as MCUs and lightweight microcontrollers), and dual-mode switching requires inference time of <50ms, interpretable decisions, and support for online lightweight updates, CART decision tree was selected as the base model after comprehensive comparison of mainstream machine learning models.

[0123] CART decision trees are the only model that simultaneously satisfies the requirements of low computational power for embedded systems, real-time inference, and interpretable decision-making. Only by improving its shortcomings such as overfitting, weak online learning ability, and coarse confidence judgment, it can be adapted to the dual-mode switching scenario of medical monitoring equipment.

[0124] II. Design of an Improved Lightweight Fusion Decision Tree (LF-DT) Model

[0125] Based on the CART classification decision tree, this patent has made three core improvements tailored to the business and hardware characteristics of medical monitoring equipment. The model remains lightweight (model parameters <100KB), with inference time <30ms, and is fully compatible with embedded devices.

[0126]

[0127] Improvement 1: Weighted branching of medical features

[0128] To address the shortcomings of traditional CART decision tree feature partitioning with equal weights, this paper combines the business priority of medical monitoring data transmission, assigns medical business weights to 10 features in 5 categories, and integrates these weights into the Gini coefficient. This achieves priority partitioning of high-priority features and strong constraints on core features, thus meeting the needs of medical scenarios.

[0129] 1. Weighting of Medical Features

[0130] Based on the core requirements of low packet loss, low latency, and high stability for medical monitoring equipment, the 10 features in 5 categories of model input are weighted according to business priority. The weights are positively correlated with the importance of medical data transmission. The features and weights are shown in the table below (the sum of the weights is 1):

[0131]

[0132] 2. Weighted Coefficient Design

[0133] Integrating medical feature weights into traditional Coefficients, design medical weighted average The coefficient gives higher priority to high-weight features when splitting nodes. The formula is: |

[0134]

[0135] Where: a represents the feature, and D1 / D2 represent the two subsets of samples after feature partitioning. The weight of medical services for feature a.

[0136] Key effect: Packet loss rate, latency, and other core medical features will be prioritized as top-level partitioning nodes in the tree, allowing the model to make decisions that first satisfy the hard constraints of medical data transmission.

[0137] Improvement 2: Dual pruning strategy for medical scenarios (to address overfitting)

[0138] Since the single hard pruning of traditional CART decision trees cannot adapt to the characteristics of small sample size and strong business constraints in medical scenarios, this patent designs a dual pruning strategy of hard pruning + medical business constraint pruning. This strategy not only limits overfitting from a structural perspective, but also avoids invalid partitioning from a medical business perspective, thereby improving the model's generalization ability.

[0139] 1. Hard pruning: During the model training phase, three hard constraints are set to limit the growth of the tree;

[0140] Maximum tree depth: 4 layers (top layer consists of core medical features, bottom layer consists of auxiliary features);

[0141] Minimum number of split samples: 15 (to avoid overfitting caused by splitting small sample nodes);

[0142] Minimum number of samples for leaf nodes: 5 (to ensure the statistical reliability of leaf nodes).

[0143] 2. Medical Business Constraint Pruning: Add new medical business rules to forcibly prune branches that do not meet medical needs. Core rule:

[0144] If the decision result of a certain branch is "switch mode", but the packet loss rate of that branch is ≥5% or the latency is ≥200ms (the threshold for failure of medical data transmission), the branch is directly pruned and determined to "do not switch". If the network stability score of a leaf node is <30 (communication failure), the decision result of that node is directly set to the current mode to avoid switching to the failed network.

[0145] Improvement 3: Incremental node update online learning (adapted to low computing power)

[0146] To address the shortcomings of traditional CART decision trees, which only support batch learning and require full retraining, and considering the low computing power of medical monitoring equipment and the small sample size for online learning, an incremental node update online learning strategy is designed. This strategy eliminates the need for full model retraining and only performs local updates on the nodes corresponding to new samples, significantly reducing hardware computing power consumption and meeting the requirement in the document to "update the model after accumulating to a set threshold".

[0147] 1. Triggering conditions for online learning

[0148] As per the documentation requirements, when 100 new training data points are accumulated, an online model update is triggered (to avoid frequent updates consuming computational resources).

[0149] 2. Core steps of incremental node update

[0150] 1) Sample matching: Input 100 new samples into the current LF-DT model, traverse the inference path of each sample, and match the leaf node it finally reaches;

[0151] 2) Node statistics update: For each leaf node, update the internal sample category statistics (number of samples for WiFi / AP / FAILURE) without recalculating feature partitioning;

[0152] 3) Node category re-determination: If the percentage of sample categories in a leaf node changes by **≥20%**, the decision category of that node is re-determined using the "majority voting method".

[0153] 4) Abnormal node detection: If the proportion of FAILURE (switching failure) in the new samples of a certain node is ≥50%, the node is marked as an "abnormal node", and a local feature re-division is performed on the parent node of the node based on the new samples (only local update, does not affect the whole tree).

[0154] 3. Advantages of online learning

[0155] Compared with traditional full retraining, incremental node updates reduce computing power consumption by more than 80%, model update time is less than 200ms, fully adapt to the hardware capabilities of embedded medical monitoring devices, and can effectively absorb new switching scenario data to achieve dynamic model iteration.

[0156] Improvement Point 4: Medical-grade tiered confidence decision-making (improving switchover reliability)

[0157] Traditional CART decision trees only output a single category, and the confidence level is coarse (only the proportion of samples in the leaf nodes is used as the confidence level), which cannot meet the needs of "low error switching and high reliability" in medical scenarios. This patent designs a medical-grade hierarchical confidence decision mechanism, which binds the confidence level to hard constraints of medical business, and realizes "hierarchical confidence level + dual judgment of business constraints", avoiding interruption of medical data transmission due to model prediction errors.

[0158] 1. Optimization of confidence calculation

[0159] The traditional single leaf node confidence score is upgraded to a path-weighted confidence score, which combines feature weights and node sample proportions for calculation. This better reflects the decision reliability in medical scenarios. The formula is as follows:

[0160]

[0161] Where: n is the number of nodes in the sample inference path, Let the feature weights of the j-th node in the path be denoted as . The sample purity of the j-th node (1- (Coefficient). Confidence level range: 0-1, with higher values ​​indicating more reliable decisions.

[0162] 2. Hierarchical confidence decision rules

[0163] Based on the operational needs of medical monitoring equipment, the confidence level is divided into three levels, and corresponding switching decision rules are formulated. Simultaneously, medical hard constraints (packet loss rate, latency, and stability) are applied to ensure the reliability of the decisions, fully meeting the requirement in the document to "control switching based on confidence level and optimal network mode."

[0164]

[0165] Key benefits: By using hierarchical confidence decision-making, the model false switching rate is reduced by more than 90%, while avoiding "blind switching under low confidence", ensuring the continuous transmission of medical monitoring data and meeting the high reliability requirements of the Internet of Things in healthcare.

[0166] The overall execution steps of the model include:

[0167] Phase 1: Offline initialization training (executed during device factory shipment / initial configuration)

[0168] This stage is the basic training stage of the model, which completes the construction and optimization of the initial CART decision tree model. The training results are deployed to the dual-mode communication module of the medical monitoring equipment to provide a basic model for real-time prediction during equipment operation, which corresponds to the core requirement of "building a machine learning model and completing training".

[0169] Step 1: Training Data Collection and Labeling

[0170] 1.1 Feature Dimension Acquisition

[0171] Five categories and ten features are extracted as model inputs. All features are closely aligned with the actual operating scenarios of medical monitoring equipment, eliminating the need for additional redundant features and reducing model complexity.

[0172]

[0173] 1.2 Sample Labeling

[0174] Using the actual switching results as labels, a three-category labeling rule is adopted to meet the online learning requirement of "recording switching success / failure":

[0175] Tag 1 (WiFi): After switching to WiFi mode, medical data transmission is stable (packet loss rate <5%, latency <200ms), and the switch was successful;

[0176] Tag 2 (AP): After switching to AP mode, medical data transmission is stable, and the switch was successful;

[0177] Tag 3 (FAILURE): Data transmission was interrupted / abnormal after switching to the target mode, and the switch failed.

[0178] 1.3 Sample Set Requirements

[0179] Collect no fewer than 500 valid samples to form an initial training set, covering typical usage scenarios of medical monitoring equipment (initial deployment, stable environment, mobile scenario, configuration mode) to ensure the model's generalization ability, and remove abnormal samples whose feature values ​​exceed the medical business failure threshold (such as packet loss rate ≥5% or latency ≥200ms).

[0180] Step 2: Training Data Preprocessing

[0181] Following data preprocessing requirements, only lightweight preprocessing operations are performed to avoid complex calculations and ensure suitability for subsequent engineering implementation. The preprocessing steps are as follows:

[0182] Outlier removal: Delete samples whose feature values ​​exceed the reasonable range for medical services (e.g., equipment temperature ≥85℃, battery power <0%).

[0183] Missing value imputation: For a small number of missing feature values, the mean of the same scene is used for imputation (e.g., if the signal strength of a mobile scene is missing, the mean of the signal strength in the mobile scene is used for imputation) to ensure the integrity of the sample.

[0184] Label encoding: Convert non-numerical labels (WiFi / AP / FAILURE) into numerical labels (0 / 1 / 2) that the model can recognize, without the need to normalize the features (a feature of the CART decision tree algorithm, avoiding redundant calculations);

[0185] Dataset partitioning: The preprocessed sample set is divided into a training set and a test set in a 7:3 ratio. The training set is used for model training, and the test set is used for model evaluation.

[0186] Step 3: Customized Feature Engineering for Medical Scenarios

[0187] Based on the core transmission requirements of medical monitoring equipment—low ​​packet loss, low latency, and high stability—medical feature weighting is added to prepare for subsequent weighted Gini coefficient partitioning. The steps are as follows:

[0188] Feature importance ranking: Based on the impact of medical services on data transmission, the 10 features are ranked in order of importance: packet loss rate > latency > network stability > signal strength > device movement range > location stability > battery level > device temperature > historical handover success rate > user configuration mode identifier;

[0189] Healthcare business weight assignment: Each feature is assigned a business weight of 0-1, with the sum of the weights being 1. Core healthcare features (packet loss rate, latency) account for more than 50%, and the specific assignments are as follows:

[0190]

[0191] Feature matrix generation: The weighted features are combined with the preprocessed samples to form a medical feature weighted matrix, which serves as the training input for the improved CART decision tree.

[0192] Step 4: Training the improved CART decision tree model

[0193] Using CART classification decision tree as the algorithm core, weighted Gini coefficients for medical features are incorporated into the traditional training process to achieve priority classification based on core medical features. The training steps are as follows:

[0194] 1) Initialize model parameters: Completely consistent with the document configuration, set maxDepth=5, minSamplesSplit=10, and add medical training parameters: minimum number of leaf node samples = 5, medical feature weight matrix = Step 3 assignment result;

[0195] 2) Weighted Gini Coefficient Feature Splitting: This method integrates the weights of medical features into the Gini coefficient calculation of the CART decision tree, replacing the traditional equal-weighted Gini coefficient. This prioritizes high-weighted medical features as top-level splitting nodes in the tree. The core calculation formula is as follows:

[0196] Where: represents the medical business weight of the feature, represents the sample set of the current node, and represents the subsample set after feature partitioning. The Gini coefficient calculation follows the traditional CART decision tree rules.

[0197] 3) Binary tree node growth: Based on the weighted Gini coefficient, features are divided sequentially from the root node to generate a binary tree structure. The top-level nodes are core medical features such as packet loss rate / latency, and the bottom-level nodes are auxiliary features such as equipment / behavior. The tree depth is strictly controlled within 5 levels.

[0198] 4) Dual-pruning optimization for medical scenarios: After node growth is complete, hard pruning + medical business constraint pruning is performed to solve the overfitting problem of traditional CART decision trees, while ensuring the hard constraints of medical business:

[0199] Hard pruning: Based on the document parameters, prune nodes with a depth of more than 5 layers and fewer than 10 split samples, and merge leaf nodes with fewer than 5 samples.

[0200] Healthcare business constraint pruning: Prune all branches where the decision result is to switch modes but the core medical indicators exceed the failure threshold (e.g., the branch decision is WiFi but the packet loss rate is ≥5%), correct the decision result of such branches to "maintain the current mode", and mark them as leaf nodes.

[0201] Step 5: Model Evaluation and Lightweight Deployment

[0202] 5.1 Model Evaluation

[0203] The model accuracy is calculated, and key performance indicators for medical scenarios are also evaluated to ensure that the model is suitable for medical data transmission requirements. The evaluation indicators are as follows:

[0204] Overall accuracy: Pattern prediction accuracy on the test set is ≥90%, and the accuracy in core scenarios (mobile / stable environment) is improved by ≥15% compared with traditional CART decision trees;

[0205] Accuracy of prediction for core medical indicators: The accuracy of pattern prediction for packet loss rate / delay-related features is ≥95%, avoiding data transmission interruptions caused by misjudgment of core medical indicators;

[0206] Confidence validity: The confidence level of the prediction results matches the actual handover success rate by ≥85%, ensuring that the confidence level can be used as the basis for "handover control" in the document.

[0207] If the model does not meet the evaluation criteria, return to step 1 to supplement the corresponding scenario samples and retrain.

[0208] 5.2 Lightweight Deployment

[0209] The trained improved CART decision tree model is converted into a lightweight format (such as a C language array / binary file) that can be recognized by embedded devices, with the model parameter size controlled within 100KB. It is then deployed to the dual-mode communication module of the medical monitoring device to complete model initialization and generate this.predictionModel, providing a foundation for real-time prediction during device operation.

[0210] Phase 2: Online incremental update training (executed during device operation)

[0211] This stage is the dynamic iteration stage of the model, which fully follows the requirement of "realizing dynamic iterative optimization of the model through online learning". When the new training data accumulates to 100 (the threshold is set in the document), lightweight incremental training is performed locally on the device without full retraining, reducing hardware computing power consumption and enabling the model to continuously evolve with the actual use scenario.

[0212] Step 1: Accumulate online training data

[0213] During device operation, the pre-mode features, prediction results, and actual switching results are recorded in real time for each mode switch, forming online training samples. The sample format is consistent with the offline training samples. Specific recorded content includes:

[0214] Pre-training features: 5 categories and 10 real-time features before switching (with the same dimensions as the offline training features);

[0215] Prediction results: The recommended patterns and confidence levels output by the model;

[0216] Actual labels: Labels (WiFi / AP / FAILURE) based on the actual switching results, consistent with the offline training labeling rules.

[0217] When the accumulated valid online samples reach 100, the device is triggered to perform incremental update training locally.

[0218] Step 2: Incremental training data preprocessing

[0219] Lightweight preprocessing is performed on 100 online samples, including only outlier removal and feature weight matching. This requires no re-split of the dataset and takes less than 50ms, making it suitable for real-time devices.

[0220] Remove abnormal samples whose feature values ​​exceed the threshold for failure of medical services;

[0221] The features of online samples are matched with the weights of medical features trained offline to generate a weighted feature vector that is consistent with the existing feature dimensions of the model.

[0222] Step 3: Improved CART decision tree incremental node update training

[0223] Unlike traditional CART decision trees that require full retraining, this approach uses a local node update strategy. It only trains and updates nodes in the model that match the new samples, without altering the overall model structure. The core steps are as follows:

[0224] New sample path matching: Input 100 preprocessed online samples into the model in the current device, traverse the inference path of each sample, match the leaf node it finally reaches, and record the number of new samples and label distribution of each leaf node;

[0225] Leaf node statistics update: For each matched leaf node, update its internal sample category statistics (number of samples for WiFi / AP / FAILURE), and incorporate the new samples into the node statistics without recalculating the feature partitioning;

[0226] Leaf node decision re-determination: If the sample label distribution of a leaf node changes by ≥20% (e.g., the original WiFi sample proportion is 80%, but it drops to 50% after the new sample is incorporated), the decision category of the node is re-determined using the majority voting method, and the node output is updated.

[0227] Local re-segmentation of abnormal nodes: If the proportion of FAILURE (failed switching) samples in a certain leaf node is ≥50%, it is marked as an abnormal node. Based on the new samples, a local feature re-segmentation is performed on the parent node of this node (only the weighted Gini coefficient is used to reselect the segmentation features, without affecting other nodes), and the local inference path is optimized.

[0228] Step 4: Model Parameter Update and Validation

[0229] Parameter update: The node statistics, decision categories, local partitioning features, and other parameters after incremental training are overwritten with the corresponding parameters of the original model in the device to complete the model iteration. The updated model still maintains the basic configuration of maxDepth=5 and minSamplesSplit=10, which is consistent with the requirements of the document.

[0230] Local lightweight validation: Randomly select 10 new samples to validate the updated model and ensure that the prediction accuracy is ≥85%. If the accuracy is not met, abandon this parameter update, retain the original model, and continue to accumulate training data.

[0231] Step 5: Archiving Training Data

[0232] The 100 samples used in this incremental training were archived, duplicate / invalid samples were removed, and valid samples were stored locally on the device as supplementary data for subsequent incremental training to avoid sample loss.

[0233] II. Intelligent Predictive Switching Method

[0234] This method, known as "switching decision entry points," predicts the current optimal network mode using a trained model. The execution flow is as follows:

[0235] 1. Obtain the current device and network status, and extract the real-time feature matrix using a feature extractor;

[0236] 2. Predict the optimal network pattern based on real-time features;

[0237] 3. Simultaneously return the prediction confidence level and alternative modes to provide more reference for switching decisions, and finally return the structured prediction results.

[0238] III. Online Learning Methods

[0239] This method enables "dynamic iterative optimization" of the model, allowing it to continuously evolve as the actual scenario changes. The execution flow is as follows:

[0240] 1. Extract the device status features before the switch, and combine them with the switch result (success / failure) to generate new training data (labeled as the switch target mode or "FAILURE").

[0241] 2. Store the new data in the trainingData array to accumulate training samples;

[0242] 3. When the cumulative number of samples reaches an integer multiple of 100, the model is automatically retrained and the model parameters are updated to ensure that the model always adapts to the latest scene changes.

[0243] The above solution enables dual-mode access of medical monitoring equipment to the medical platform, providing basic monitoring data for remote medical diagnosis. It also supports dual-mode communication, effectively ensuring communication stability and reliability, and can automatically switch communication modes. Hysteresis comparison is used during switching to effectively avoid frequent switching.

[0244] Obviously, the specific implementation of this invention is not limited to the above-described methods. Any non-substantial improvements made using the inventive concept and technical solution of this invention are within the protection scope of this invention.

Claims

1. A dual-mode intelligent connection switching method for a medical monitoring device, characterized in that: This includes a built-in dual-mode communication module for medical testing equipment, which is used to access the medical platform. The dual-mode communication module provides communication mode one and communication mode two, and the medical platform can be accessed through one of the two communication modes.

2. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 1, characterized in that: The dual-mode communication module provides WiFi mode and AP mode and monitors the current communication status in real time to switch between the two; wherein mode one is WiFiSTA mode and communication mode two is AP hotspot mode.

3. A dual-mode intelligent connection switching method for a medical monitoring device as described in claim 1 or 2, characterized in that: After the dual-mode communication module is started, it connects to the medical platform using the current preset mode or the default mode. Then, it monitors the status information of the current communication mode in real time through an intelligent switching strategy and completes the switching between the two communication modes based on the monitored status information.

4. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 3, characterized in that: The intelligent handover strategy includes any one or a combination of the following: an adaptive handover method based on signal quality, a scenario-aware handover method based on application scenarios, and a historical learning handover method based on machine learning. The intelligent handover strategy is used to monitor and switch communication modes in real time.

5. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 4, characterized in that: Adaptive handover methods based on signal quality include: Collect network metrics data, including signal strength, packet loss rate, latency, bandwidth, stability, and connection hold time, and ensure that the data collection period does not exceed a set time threshold and meets the real-time transmission requirements of medical data. Scores for Mode 1 and Mode 2 are calculated based on the collected network indicator data; Whether to switch network modes is determined based on the scores of Mode 1 and Mode 2.

6. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 5, characterized in that: At each set period, a quality assessment is performed on the current network mode and the alternative network modes to obtain the scores of communication mode one and communication mode two. If the score of the alternative network mode is greater than the sum of the score of the current network mode and the buffer threshold, it is determined to switch the network mode and switch to another communication mode to connect to the medical platform.

7. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 4, characterized in that: The scenario-aware switching method based on application scenarios involves dynamically collecting device status indicators, identifying the current scenario through rule-based judgment, and finally returning the scenario name, and selecting the corresponding network communication mode based on the scenario name.

8. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 7, characterized in that: The collected device status indicators include initial power-on status, network stability score, device movement range, user behavior analysis, and time elapsed since the last mode configuration. The current scenario is determined by classifying scenarios based on preset rules.

9. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 4, characterized in that: The historical learning switching method based on machine learning includes building a machine learning model, training the built machine learning model, predicting the current optimal network mode through the trained machine learning model, and completing the switching of the network model. The machine learning model predicts the optimal network mode and its confidence level based on real-time features by acquiring the current device and network status output, and performs switching control based on the confidence level and the optimal network mode.

10. The dual-mode intelligent connection switching method for a medical monitoring device as described in claim 9, characterized in that: The machine learning mode adopts an online learning approach to achieve dynamic iteration and optimization of the model. The device state characteristics before each switch and the switch result are used as new training data. When the new training data accumulates to a set threshold, the machine learning model is retrained and the model parameters are updated using the accumulated training data.

Images