A hierarchical program control and remote coordination system for deep brain stimulation of Parkinson's disease

Abstract

The embodiment is a Parkinson's disease deep brain electrical stimulation hierarchical program control and remote cooperative system, candidate action sets are generated and output by an action output end based on observation data, disease information and current hierarchical state of a patient, a final judgment is made by a doctor end based on on-site data collected by a local end and the candidate action sets output by the action output end, and then a final executed action is determined, the determined action is input to the local end after the doctor end determines the final executed action, and the local end executes based on the received action, the embodiment forms an automatic program control decision pipeline from "raw data - scene recognition - candidate generation - safety filtering", and through hierarchical determination and candidate set screening, clinical consensus and safety boundaries are solidified into system logic, so that program control decision is more standardized and reproducible, and then human differences are reduced.

Description

Technical Field

[0001] This application relates to the fields of neuromodulation, deep brain stimulation programming, medical informatics, and remote collaborative decision support, specifically to a hierarchical programming and remote collaborative system for deep brain stimulation in Parkinson's disease. Background Technology

[0002] Deep brain stimulation (DBS) has become an important component of advanced therapy for Parkinson's disease. For patients undergoing DBS treatment, the parameters are not set once and then remain unchanged indefinitely. Instead, multiple reprogramming processes are required, focusing on contact point or channel combinations, stimulation amplitude, current or voltage modes, pulse width, frequency, stimulation modality, program switching, and phased plans. In real clinical practice, the task of DBS programming is not to find an abstract "optimal value" in an infinite parameter space, but rather to progressively test, accept, freeze, revert, or upgrade a finite set of setting candidates within the boundaries of equipment support, clinical safety, physician confirmation, and subsequent rollback.

[0003] In existing technologies, DBS programming schemes related to Parkinson's disease can be broadly categorized into several types. The first type is traditional outpatient trial-and-error programming, which relies on the operator's experience to find an optimal setting by gradually adjusting the contact point, amplitude, pulse width, and frequency. The second type includes image-guided, lead reconstruction, connectomic targeting, or parameter prediction schemes, which attempt to narrow down the parameter search space or provide initialization suggestions. The third type is adaptive stimulation schemes based on local electrophysiological signals, biomarkers, or adaptive modes, which mainly focus on stimulation regulation rules or mode on / off. The fourth type is remote programming, remote review, and remote consultation systems, which primarily address geographical and resource constraints. The fifth type includes programmer history, tested setting records, and follow-up reference tools, which mainly accumulate historical sessions and human experience. Existing technologies typically revolve around single outpatient programming sessions, single parameter predictions, or single remote functions, lacking a unified hierarchical programming framework and failing to incorporate actions with different time scales, risk levels, and role permissions into the same system. Summary of the Invention

[0004] In view of the technical problems existing in the background art, this application provides a hierarchical programming and remote collaboration system for deep brain stimulation in Parkinson's disease. This system solidifies clinical consensus and safety boundaries into system logic through hierarchical determination (based on rules) and candidate set screening (based on templates and neighborhood constraints), making the programming decision more standardized and reproducible, thereby reducing human differences.

[0005] This application provides a layered programming and remote coordination system for deep brain stimulation in Parkinson's disease, comprising:

[0006] The action output terminal is used to output the set of candidate actions;

[0007] The doctor's end is used to confirm the candidate actions within the candidate action set;

[0008] The main body is used to execute the candidate actions confirmed by the doctor's end during testing;

[0009] The action output terminal includes:

[0010] The data acquisition module is used to acquire patient observation data and disease progress information;

[0011] The hierarchical determination module is used to determine the hierarchical status of the patient based on the observation data and the disease course information;

[0012] The candidate set filtering module is used to match candidate actions based on the observation data, the disease course information, and the current hierarchical status.

[0013] The hard constraint filtering module is used to filter the candidate actions based on a preset safety threshold and form a set of candidate actions;

[0014] The current hierarchical status is used to determine the stage of the patient's programming.

[0015] In some embodiments, the current hierarchical state includes the initialization layer, the outpatient review layer, and the long-term dynamic optimization layer;

[0016] When there is no historical stable setting in the disease course data, the hierarchical determination module outputs the current hierarchical state as the initialization layer;

[0017] When the disease course data shows a stable setting and the observation data shows a decline in efficacy, the hierarchical determination module outputs the current hierarchical status as outpatient review level.

[0018] When multiple stable settings exist in the disease course data, the hierarchical determination module outputs that the current hierarchical state is a long-term dynamic optimization layer.

[0019] In some embodiments, the system further includes an action library module, which has a preset limited action library, and the candidate set filtering module matches candidate actions based on the preset limited action library.

[0020] In some embodiments, a stability settings snapshot library module is further included, which is used to store stability settings in the disease course information in chronological order.

[0021] In some embodiments, a rollback module is also included. When the local terminal reports that executing the candidate action causes obvious adverse reactions or no obvious benefits, the rollback module performs a rollback operation. The rollback operation includes controlling the local terminal to execute the most recent stable setting in the stable setting snapshot library module.

[0022] In some embodiments, a collaboration terminal is also included, which is used to collect the session content of the action output terminal, the remote terminal, the doctor terminal and the local terminal, and to perform consistency analysis on the session content of the action output terminal, the remote terminal, the doctor terminal and the local terminal.

[0023] In some embodiments, when the collaborating end determines that the session content of the action output end, the remote end, the doctor end, and the local end is inconsistent, the rollback module performs a rollback operation.

[0024] In some embodiments, the rollback operation further includes sending a doctor's review instruction to the doctor's terminal.

[0025] In some embodiments, a locking module is also included. After the rollback module performs the rollback operation, the locking module performs a freeze execution on the local terminal, and the local terminal only executes the most recent stable setting.

[0026] In some embodiments, a remote terminal is also included, which is used to provide recommendations for the set of candidate actions output by the action output terminal; the doctor terminal confirms the candidate actions in the set of candidate actions based on the recommendations.

[0027] Beneficial effects:

[0028] This embodiment is a hierarchical programming and remote collaboration system for deep brain stimulation in Parkinson's disease. The system generates and outputs a set of candidate actions based on the patient's observation data, disease progression information, and current hierarchical status. The doctor's end makes a final judgment based on the local data collected and the candidate action set output by the action output end, determining the final action to be executed. After determining the final action, the doctor's end inputs the determined action to the local end, which then executes the action. This embodiment forms an automated programming decision-making pipeline from "raw data → scene recognition → candidate generation → safety filtering." Through hierarchical judgment (rule-based) and candidate set screening (template and neighborhood constraints), clinical consensus and safety boundaries are solidified into system logic, making programming decisions more standardized and reproducible, thereby reducing human error.

[0029] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0030] To more clearly illustrate the technical solutions of this application, the accompanying drawings used in this application will be briefly described below. Obviously, the drawings described below are merely some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without any creative effort.

[0031] Figure 1 This is a schematic diagram of the framework of the Parkinson's disease deep brain stimulation layered programming and remote collaborative system in the embodiments of this application;

[0032] Figure 2 This is a schematic diagram of the system framework for the action output portion in an embodiment of this application. Detailed Implementation

[0033] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0034] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0035] In this document, the term "comprising" indicates the presence of a described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," with exclusions being otherwise specifically emphasized. Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying one or more of the feature. In the description of embodiments of this application, unless otherwise stated, "a plurality of" means two or more.

[0036] In this text, the term "and / or" simply describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this text generally indicates that the preceding and following related objects have an "or" relationship.

[0037] Deep brain stimulation (DBS) has become an important component of advanced therapy for Parkinson's disease. For patients undergoing DBS treatment, the parameters are not set once and then remain unchanged indefinitely. Instead, multiple reprogramming processes are required, focusing on contact point or channel combinations, stimulation amplitude, current or voltage modes, pulse width, frequency, stimulation modality, program switching, and phased plans. In real clinical practice, the task of DBS programming is not to find an abstract "optimal value" in an infinite parameter space, but rather to progressively test, accept, freeze, revert, or upgrade a finite set of setting candidates within the boundaries of equipment support, clinical safety, physician confirmation, and subsequent rollback.

[0038] In existing technologies, DBS programming schemes related to Parkinson's disease can be broadly categorized into several types. The first type is traditional outpatient trial-and-error programming, which relies on the operator's experience to find an optimal setting by gradually adjusting the contact point, amplitude, pulse width, and frequency. The second type includes image-guided, lead reconstruction, connectomic targeting, or parameter prediction schemes, which attempt to narrow down the parameter search space or provide initialization suggestions. The third type is adaptive stimulation schemes based on local electrophysiological signals, biomarkers, or adaptive modes, which mainly focus on stimulation regulation rules or mode on / off. The fourth type is remote programming, remote review, and remote consultation systems, which primarily address geographical and resource constraints. The fifth type includes programmer history, tested setting records, and follow-up reference tools, which mainly accumulate historical sessions and human experience. Existing technologies typically revolve around single outpatient programming sessions, single parameter predictions, or single remote functions, lacking a unified hierarchical programming framework and failing to incorporate actions with different time scales, risk levels, and role permissions into the same system.

[0039] To address the technical problem that existing technologies typically revolve around single-outpatient programming, single-parameter prediction, or single remote functions, lacking a unified hierarchical programming framework and failing to incorporate actions with different time scales, risk levels, and role permissions into the same system, this application provides a hierarchical programming and remote collaboration system for deep brain stimulation in Parkinson's disease. Through hierarchical determination (rule-based) and candidate set screening (template and neighborhood constraints), clinical consensus and safety boundaries are solidified into system logic, making programming decisions more standardized and reproducible, thereby reducing human error.

[0040] This application provides a layered programming and remote collaboration system for deep brain stimulation (DBS) in Parkinson's disease, designed for parameter management in post-DBS patients.

[0041] DBS (Deep Brain Stimulation) is a treatment method that modulates neural activity by sending electrical impulses to specific nuclei in the brain (such as the subthalamic nucleus and the medial part of the globus pallidus) through implanted electrodes. It is mainly used for movement disorders such as Parkinson's disease.

[0042] The DBS system comprises three key components:

[0043] Electrodes (Leads): Specific targets in the brain implanted through small holes in the skull.

[0044] Extension Wire: Connects the electrodes to the pulse generator and is implanted under the skin.

[0045] Implantable Pulse Generator (IPG): Commonly known as a "battery," it is usually implanted subcutaneously in the chest below the collarbone and serves as the power source for the entire system. Doctors can non-invasively adjust the parameters of the electrical pulses it emits (such as frequency and intensity) using external devices to optimize treatment outcomes.

[0046] DBS programmable control refers to the process of setting and adjusting the electrical pulse parameters (contacts, amplitude, pulse width, frequency, mode, etc.) of a pulse generator.

[0047] like Figure 1-2 As shown in the figure, this application provides a layered programming and remote collaboration system for deep brain stimulation in Parkinson's disease, including: an action output terminal, a doctor terminal, and a host terminal, wherein the action output terminal is used to output a set of candidate actions; the doctor terminal is used to confirm the candidate actions in the set of candidate actions; and the host terminal is used to execute and test the candidate actions confirmed by the doctor terminal.

[0048] As can be understood, the local terminal refers to the field operating unit located next to the patient that directly interacts with the DBS programmer. It is typically operated by clinicians, nurses, or trained technicians. The local terminal is the only execution end capable of actually writing parameters to the DBS device and is also the main node for collecting real-time symptom feedback and adverse reactions.

[0049] The physician's end refers to the clinical decision-making node with final confirmation authority, typically operated by the attending physician or authorized senior clinician. The physician's end can make a final judgment on high-risk actions based on local field data, suggestions provided by the remote end, and a bounded candidate set automatically generated by the system. The physician's end does not directly operate the DBS programmable device (device writes are performed locally), but its confirmation is an indispensable prerequisite for certain critical actions (such as accepting new stability settings, switching contacts / modes, and performing adaptive actions).

[0050] In this embodiment, the action output terminal generates and outputs a set of candidate actions based on the patient's observation data and disease progress information. The doctor's terminal makes a final judgment based on the on-site data collected locally and the set of candidate actions output by the action output terminal, and then decides on the final action to be executed. After determining the final action to be executed, the doctor's terminal inputs the determined action to the local terminal, and the local terminal executes the action based on the received action.

[0051] Specifically, in this embodiment, the action output end includes a data acquisition module, a hierarchy determination module, a candidate set filtering module, and a hard constraint filtering module. The data acquisition module is used to acquire the patient's observation data and disease progress information; the hierarchy determination module is used to determine the hierarchy based on the observation data and disease progress information to obtain the patient's current hierarchy status; the candidate set filtering module is used to match candidate actions based on the observation data, disease progress information, and current hierarchy status; and the hard constraint filtering module is used to filter candidate actions based on a preset safety threshold and form a candidate action set.

[0052] In this embodiment, the observation data includes real-time symptom observation, historical summaries, device capabilities, patient complaints, adverse reactions, and optional external interface inputs (such as image summaries, biomarker effectiveness markers, signal quality markers, etc.). Disease course information includes the patient's basic disease information (Parkinson's disease classification, disease duration, main symptoms, etc.), previous DBS programming history (tested settings, responses, and adverse reactions for each outpatient visit), and existing stable settings. Stable settings refer to actions that have been executed as test settings, achieved preset symptom improvement or acceptable symptom-side balance within the observation window, exhibited no unacceptable adverse reactions, met safety constraints, and were confirmed and accepted by the physician.

[0053] The current hierarchical state is used to determine the stage of patient programming. It is understood that the current hierarchical state directly determines the macro-level stage of the entire programming session, thus avoiding the use of the same parameter tuning logic in vastly different scenarios such as postoperative initialization, outpatient review, long-term follow-up, and anomaly handling. In this embodiment, the hierarchical determination result of the hierarchical determination module directly determines the "leniency" of subsequent candidate set generation, the allowed action types, and the permission boundaries for remote collaboration, achieving risk-level management.

[0054] In this embodiment, after the data acquisition module acquires the patient's observation data and disease progress information, it transmits these data to the hierarchical determination module. The hierarchical determination module performs a hierarchical determination based on the observation data and disease progress information to obtain the patient's current hierarchical status. The candidate set filtering module matches candidate actions based on the observation data, disease progress information, and current hierarchical status. The hard constraint filtering module filters candidate actions based on a preset safety threshold, forming a candidate action set. This transforms the raw clinical data into a controlled, bounded set of candidate actions, ensuring that all subsequent operations, such as local testing, remote suggestions, and doctor confirmation, run on a safe and predictable track.

[0055] In this embodiment, the data acquisition module, hierarchical judgment module, candidate set screening module, and hard constraint screening module in the action output end form an automated programmable decision-making pipeline from "raw data → scene recognition → candidate generation → safety filtering". Through hierarchical judgment (based on rules) and candidate set screening (based on templates and neighborhood constraints), clinical consensus and safety boundaries are solidified into system logic, making programmable decisions more standardized and reproducible, thereby reducing human differences.

[0056] In some embodiments, the system further includes a remote terminal, which provides recommendations for the set of candidate actions output by the action output terminal.

[0057] The remote endpoint refers to a port for communication with experts or collaborative nodes who are not physically present at the patient's location, via network connection or other means. It is typically operated by remote experts (such as doctors from higher-level hospitals or technical support engineers) using a dedicated client or web interface. The remote endpoint cannot directly write any parameters to the DBS device, nor can it accept new stable settings; all interactions are presented as suggestions.

[0058] In this embodiment, after the remote terminal acquires the patient's observation data, disease progress information, and the candidate action set output by the action output terminal, it provides recommendations for candidate actions based on the observation data, disease progress information, and candidate action set. The doctor makes a final judgment based on the on-site data collected locally, the recommendations provided by the remote terminal, and the candidate action set output by the action output terminal, and then decides on the final action to be executed. The remote terminal can provide sorting suggestions on the candidate action set output by the action output terminal, assisting the local doctor in prioritizing the testing of the most likely effective candidates, reducing the number of ineffective trials, and thus improving treatment efficiency.

[0059] In some embodiments, the current hierarchical state includes an initialization layer, an outpatient review layer, and a long-term dynamic optimization layer. Specifically, when there are no historical stable settings in the medical records, the hierarchical determination module outputs the current hierarchical state as the initialization layer; when there are stable settings in the medical records and the observed data shows a decline in efficacy, the hierarchical determination module outputs the current hierarchical state as the outpatient review layer; when there are multiple stable settings in the medical records, the hierarchical determination module outputs the current hierarchical state as the long-term dynamic optimization layer.

[0060] Understandably, the initialization layer is used for the first postoperative programming or when no stable settings are available (i.e., the first postoperative programming, stable settings failure, physician-triggered major reset, equipment replacement, or baseline loss). Its main task is to form the first set of acceptable initial stable settings.

[0061] Outpatient review layer: Used when there is a stable setting but the efficacy has declined or enhanced testing is required (i.e., there is a stable setting available, the outpatient review program expires, the efficacy has declined or the side effect boundary has narrowed, or the doctor initiates the process). The core is to conduct limited testing, acceptance, rollback, and upgrade within the current stable setting neighborhood.

[0062] Long-term dynamic optimization layer: Used for continuous optimization management based on existing stable configuration clusters or phased plans, with tasks including phased fine-tuning or long-term maintenance. It mainly performs small-step adjustments within preset boundaries.

[0063] In this embodiment, the hierarchical determination module performs hierarchical determination based on observation data and disease progression information, dynamically classifying the programmed session into the correct risk / timescale scenario to avoid cross-scenario logical mismatch. The hierarchical determination result directly determines the "leniency" of subsequent candidate set generation, the allowed action types, and the permission boundaries of remote collaboration. By setting the "degree of freedom" for candidate set generation under different levels, a "divide and conquer" risk classification control is achieved, avoiding the use of the same search strategy to handle all scenarios. For example, the initialization layer has a wider (but still limited) candidate set, the outpatient review layer has a strict neighborhood, and the long-term optimization layer only allows small steps.

[0064] In some embodiments, the system also includes an action library module, which pre-defines a limited action library. The candidate set filtering module matches candidate actions based on the pre-define limited action library. It is understood that the pre-define limited action library transforms the programming experience of clinical experts into limited, reusable action templates, ensuring that subsequent hierarchical adaptation, security filtering, access control, and audit analysis are all based on the same set of explicit action semantics.

[0065] For example, in this embodiment, the limited action library includes the following actions:

[0066] B-A4 generates a short list of contact points / channels;

[0067] B-A5 generates the initial parameter template;

[0068] B-A6 is tested in the next setting within the candidate action set;

[0069] B-A7 accepts the current settings as the new stable settings;

[0070] B-A8 reverts to the last stable setting;

[0071] B-A9 upgraded doctor review;

[0072] B-A10 Small step size increase;

[0073] B-A11 Small step size decreases the amplitude;

[0074] B-A12 updates the mode / threshold within the validation envelope;

[0075] B-A13 pauses adaptive mode and reverts to stable cDBS.

[0076] Among them: B-A6, B-A7, B-A8, and B-A9 are the core main actions of the independent main axis of this case; B-A4 and B-A5 mainly serve the initialization layer; B-A10 and B-A11 mainly serve the long-term dynamic optimization layer; B-A12 and B-A13 only appear as subordinate or implementation actions when qualified and authorized, and should not return to the independent main axis.

[0077] In this embodiment, the matching of candidate actions is not unlimited, but rather based on the current level, current stability settings, current device capabilities, security / permission status, and session target. The matching of candidate actions is subject to the following conditions:

[0078] 1. The number of parameter dimensions that can be changed in a single action is limited (preferably single-dimensional or a few-dimensional).

[0079] 2. The step size of each parameter dimension is the discrete step size supported by the device;

[0080] 3. Permissible combinations of contact points / channels are limited by the current permitted set and prohibited areas;

[0081] 4. Stimulation modes are limited to the set allowed under the current level and permissions;

[0082] 5. The changed settings must meet the boundaries of current / voltage, pulse width, frequency, charge density, TEED, battery, etc.

[0083] 6. The candidate set is associated with the current stable settings to form a version.

[0084] In this embodiment, constraints such as step size, contact point, mode, and physical boundary ensure that no candidate exceeds the safe range. Single-dimensional changes and neighborhood constraints conform to the cautious trial-and-error principle of clinical programming, avoiding aggressive parameter tuning. Version association and limited parameter dimensions make the reasons and sources of each adjustment clear and traceable. Settings must comply with the device capabilities. The above restrictions constitute the matching and generation specifications for candidate actions, thereby ensuring the safety, executability, auditability, clinical rationality, and system verifiability of the matched and generated candidate actions.

[0085] In some embodiments, a stable setting snapshot library module is also included. This module stores stable settings in the course information in chronological order. It is understood that, in this embodiment, the stable setting snapshot library module is responsible for persistently storing all formally accepted (B-A7) stable settings in the course information in chronological order, thereby forming an information chain capable of recording DBS programmable information. The stable setting snapshots within the stable setting snapshot library module provide clear anchor points for the candidate set filtering module to match and generate candidate actions, enabling it to quickly locate the current stable setting and generate domain candidates based on it.

[0086] In some embodiments, a rollback module is also included. When the local terminal reports that executing a candidate action causes a significant adverse reaction or no significant benefit, the rollback module performs a rollback operation. The rollback operation includes controlling the local terminal to execute the most recent stability setting from the stability setting snapshot library module. In this embodiment, the rollback module is mainly used to implement a safety fallback. Once the rollback module identifies a clear adverse reaction or invalid result, the system forcibly interrupts the current test sequence. Simultaneously, the rollback module directly calls the complete parameter set of the most recent snapshot in the snapshot library, immediately and accurately bringing the patient from a high-risk or non-benefit state back to the previously validated safety baseline, thereby ensuring patient safety.

[0087] In some embodiments, the rollback operation also includes sending a doctor's review instruction to the doctor's end. In this embodiment, the rollback operation not only includes parameter rollback, but should also automatically send a doctor's review instruction to the doctor's end to ensure that the doctor is aware of and intervenes in the rollback event in a timely manner, forming a complete closed loop of "action → abnormality → rollback → review".

[0088] In some embodiments, a locking module is also included. After the rollback module performs a rollback operation, the locking module freezes the execution on the local end, and the local end only executes the most recent stable setting. It is understood that when the rollback module performs a rollback operation, the locking module is triggered simultaneously. At this time, the local end rolls back to the last verified safe and stable setting, and freezes the setting adjustment port on the local end, entering a conservative mode. This prevents further parameter adjustments without a clear cause, forming a procedural safety buffer and avoiding the risky behavior of doctors trying "another candidate" after side effects occur, thus eliminating the possibility of secondary harm from the process.

[0089] In some embodiments, a collaboration terminal is also included. This collaboration terminal collects session content from the action output terminal, remote terminal, doctor terminal, and local terminal, and performs consistency analysis on the session content from these terminals. In this embodiment, the collaboration terminal aggregates all session-related content (state changes, action commands, suggestions, confirmations, logs, etc.) generated by the local terminal, remote terminal, doctor terminal, and action output terminal in real time. It performs version comparison, conflict detection, and causal verification on the collected multi-terminal information to ensure that the session state seen by all participants is consistent, traceable, and unambiguous. This ensures that all decisions and actions are executed within a consistent and controllable framework, thereby achieving the technical effect of "remote collaboration without loss of control, local operation without silos, and audit traceability without ambiguity."

[0090] In some embodiments, when the collaborating end determines that the session content of the action output end, the remote end, the doctor end, and the local end is inconsistent, the rollback module performs a rollback operation. In this embodiment, the collaborating end maintains an authoritative session state (including the current level, stable setting version, candidate set version, session progress stage, lock flag, etc.). Each time a message is received, the state claimed by the sender is compared with the authoritative state. If a version lag, state conflict, violation of state machine rules, or permission overreach is found, and cannot be resolved through automatic synchronization (e.g., the sender forcibly ignores the synchronization request), it is determined to be "seriously inconsistent," and the collaborating end immediately calls the rollback module to perform a rollback operation, restoring the local end and the action output end to the most recent stable setting.

[0091] In this embodiment, the collaborating end can also check whether the initiating end of each action has the permission to execute the action, preventing the local end from erroneously executing due to software errors or human misoperation sending "unauthorized instructions", thereby reducing the trust risk in remote collaboration.

[0092] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application of the technical solution and the constraints involved. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0093] When the embodiments of this application are implemented using software, they can be implemented entirely or partially in the form of a computer program product. That is, the implementation of all or part of the processes in the methods of the above embodiments can also be accomplished by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, the computer-readable medium does not include electrical carrier signals and telecommunication signals.

[0094] It should be noted that this application is not limited to the above-described embodiments. The above embodiments are merely examples, and any embodiments with the same structure and effect as the technical concept within the scope of this application are included in the technical scope of this application. Furthermore, various modifications that can be conceived by those skilled in the art to the embodiments, and other ways of constructing by combining some of the constituent elements of the embodiments, without departing from the spirit of this application, are also included in the scope of this application.

Claims

1. A layered programming and remote collaborative system for deep brain stimulation in Parkinson's disease, characterized in that, include: The action output terminal is used to output the set of candidate actions; The doctor's end is used to confirm the candidate actions within the candidate action set; The main body is used to execute the candidate actions confirmed by the doctor's end during testing; The action output terminal includes: The data acquisition module is used to acquire patient observation data and disease progress information; The hierarchical determination module is used to determine the hierarchical status of the patient based on the observation data and the disease course information; The candidate set filtering module is used to match candidate actions based on the observation data, the disease course information, and the current hierarchical status. The hard constraint filtering module is used to filter the candidate actions based on a preset safety threshold and form a set of candidate actions; The current hierarchical status is used to determine the stage of the patient's programming.

2. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 1, characterized in that, The current hierarchical status includes the initialization layer, the outpatient review layer, and the long-term dynamic optimization layer; When there is no historical stable setting in the disease course data, the hierarchical determination module outputs the current hierarchical state as the initialization layer; When the disease course data shows a stable setting and the observation data shows a decline in efficacy, the hierarchical determination module outputs the current hierarchical status as outpatient review level. When multiple stable settings exist in the disease course data, the hierarchical determination module outputs that the current hierarchical state is a long-term dynamic optimization layer.

3. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 1, characterized in that, It also includes an action library module, which has a preset limited action library, and the candidate set filtering module matches candidate actions based on the preset limited action library of the action library module.

4. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 1, characterized in that, It also includes a stable settings snapshot library module, which is used to store stable settings in the disease course information in chronological order.

5. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 4, characterized in that, It also includes a rollback module, which performs a rollback operation when the local terminal reports that executing the candidate action causes obvious adverse reactions or no obvious benefits; wherein, the rollback operation includes controlling the local terminal to execute the most recent stable setting in the stable setting snapshot library module.

6. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 5, characterized in that, It also includes a collaboration terminal, which is used to collect the session content of the action output terminal, the remote terminal, the doctor terminal and the local terminal, and to perform consistency analysis on the session content of the action output terminal, the remote terminal, the doctor terminal and the local terminal.

7. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 6, characterized in that, When the collaboration terminal determines that the session content of the action output terminal, the remote terminal, the doctor terminal, and the local terminal is inconsistent, the rollback module performs a rollback operation.

8. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 4, characterized in that, The rollback operation also includes sending a doctor's review instruction to the doctor's terminal.

9. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 4, characterized in that, It also includes a locking module. When the rollback module performs the rollback operation, the locking module freezes the execution of the local terminal, and the local terminal only executes the most recent stable setting.

10. The Parkinson's disease deep brain stimulation layered programming and remote coordination system according to claim 1, characterized in that, It also includes a remote terminal for providing recommendations to the candidate action set output by the action output terminal; the doctor terminal confirms the candidate actions in the candidate action set based on the recommendations.

Images