A safety gate system for individualized medication adjustment of parkinson's disease

Abstract

This invention discloses a safety gating system for personalized medication dispensing in Parkinson's disease. The system uses a version anchoring module to template candidate action packages and verify version consistency, proactively identifying risks such as mismatched snapshots and lack of stable fallback plans. A safety constraint screening module performs initial risk screening, and a risk grading module classifies risks into different levels. Doctors then confirm the grading before execution and feedback is received. Finally, a log management module records the process and handles anomalies. This system integrates candidate medication dispensing actions, snapshot management, stable plan anchoring, anomaly fallback, and audit responsibility into a complete workflow for Parkinson's disease medication dispensing. Specifically adapted to the medication dispensing scenario for Parkinson's disease, it effectively improves the safety of the personalized medication dispensing process, achieving traceability and controllability throughout the entire process, and solving the problem of insufficient integration in existing technologies.

Description

Technical Field

[0001] This invention relates to the field of smart healthcare, and more particularly to a safety gating system for personalized medication administration in Parkinson's disease. Background Technology

[0002] Parkinson's disease drug treatment is characterized by continuous adjustment, long-term evolution, and multi-objective trade-offs. In real clinical practice, doctors typically need to make decisions in outpatient settings based on the patient's recent motor symptoms, motor complications, non-motor side effects, adherence, medication burden, and patient preferences. These decisions include whether to maintain the current regimen, increase or decrease medications, adjust single doses, adjust dosing times, adjust dosing frequencies, add or withdraw adjuvant medications, or postpone treatment and increase the level of review. However, what truly affects clinical safety is not only whether the "candidate medication adjustment action itself is reasonable," but also whether the snapshot of the current regimen on which the candidate action depends is still effective, whether there is a stable regimen that can be rolled back, how the action is confirmed by the doctor, how it is communicated to the patient, whether the patient follows the instructions on time, whether any abnormal feedback occurs after execution, and how to promptly freeze subsequent actions and revert to a conservative state when side effects, abnormal adherence, symptom worsening, or missing key observation information occur.

[0003] In existing technologies, medication dispensing systems for Parkinson's disease can be broadly categorized into several types:

[0004] The first type is static or quasi-static decision support systems, which typically provide suggestions on "medication adjustment direction" or "whether adjustment is needed" based on outpatient scales, existing prescriptions, and rule bases.

[0005] The second category consists of wearable summary, symptom diary, or patient reporting assistance systems, which mainly improve the ability to identify OFF fluctuations, dyskinesia, or abnormal compliance, but mostly remain at the observation information level for reporting.

[0006] The third category is reminder, approval and messaging systems in electronic medical records or remote follow-up, which can complete notification and recording, but generally lack version governance, stable solution anchoring, rollback chain and responsibility chain tracking for candidate drug dispensing action packages;

[0007] The fourth category is automated treatment or medical order review systems that cross diseases. Although they have certain risk thresholds and review processes, they have not developed a dedicated state machine for the specific scenario of "outpatient confirmation - home execution - abnormal rollback" for Parkinson's disease.

[0008] It is evident that while existing technologies cover automated treatment risk management, medication thresholds, and general execution chains, they still lack a systematic design that integrates candidate medication action packages, protocol snapshots, stable protocol snapshots, freeze / rollback, and audit responsibility chains into a single healthcare workflow. Summary of the Invention

[0009] To address the technical issues of limited functionality and inadequate integration of security gating systems in existing Parkinson's disease clinic systems, this invention provides a solution.

[0010] To achieve the above objectives, the present invention provides a safety gating system for personalized medication administration in Parkinson's disease, comprising: a candidate action input module, a version anchoring module, a safety constraint screening module, a risk classification module, a doctor processing module, an execution module, a feedback module, and a log management module;

[0011] The candidate action input module is used to create a medication dispensing execution session and connect to the project interface; the project interface includes current observation parameters, currently confirmed protocol snapshots, protocol snapshots, and candidate action packages.

[0012] The version anchoring module is used to perform template processing and version consistency verification on the candidate action package;

[0013] The security constraint filtering module is used to perform candidate action filtering based on security constraint rules;

[0014] The risk classification module performs risk classification based on risk, confidence level, and anomaly indicators;

[0015] The doctor processing module confirms the action to be performed based on the result of the risk level;

[0016] The execution and distribution module is used to generate execution tasks and distribute them to the outpatient and home terminals after the doctor confirms them.

[0017] The feedback module is used to receive feedback on execution confirmation, non-execution, delayed execution, and exceptions.

[0018] The log management module performs freeze, upgrade review, or rollback to a stable solution based on the feedback results, and records the corresponding audit logs and writes back the results.

[0019] As an improvement to this application, the candidate action package is obtained by encapsulating candidate drug dispensing actions.

[0020] As an improvement to this application, the template processing includes:

[0021] The candidate action package is obtained and mapped to standardized fields using a unified method based on an external decision engine;

[0022] Check if the standardized fields are complete, and review or disable candidate action packages with missing fields;

[0023] The version consistency check includes:

[0024] Obtain the candidate action package and verify whether the solution snapshot confirmed by the candidate action package is equal to the specified solution snapshot in the system;

[0025] If not, the system will check whether there are any high-risk preceding actions that have not been closed, or whether the result of the most recent execution has not yet entered the evaluation window. If so, the system will prefer to freeze the new action and proceed to the upgrade review.

[0026] If so, check if there is a usable solution snapshot.

[0027] As an improvement to this application, the screening steps of the security constraint screening module include:

[0028] Generate filter items;

[0029] The selected action package is checked to see if it meets the selection criteria. If it does, the candidate action violates the constraint criteria, the reason for blocking is recorded and it is marked as prohibited. If not, a corresponding risk level is generated for the candidate action.

[0030] As an improvement to this application, the risk classification module responds to the risk level to generate a first level, a second level, a third level, and a fourth level, each with a corresponding execution action.

[0031] The first level of execution actions are: maintaining the current plan, suspending execution within the doctor's preset boundaries, or reverting to a plan triggered by a specific event;

[0032] The second level of execution action is: to adjust the dosage of the drug within a preset step size;

[0033] The actions performed at the third level are: drug switching, changes in medication on preset quantity items, and dosage changes under the red flag state;

[0034] The action to be taken at the fourth level is: entry is not permitted.

[0035] As an improvement to this application, the doctor processing module is used to generate corresponding confirmation and authorization actions for different risk levels; wherein the confirmation action is:

[0036] The permission actions for the first level include whether to allow the execution of batch confirmation or single confirmation actions;

[0037] The permitted actions for the second level include: confirming each item and setting monitoring points;

[0038] The permission actions for the third level include: a case confirmation interface that records the confirmation reason, exception explanation, whether automatic rollback is allowed, and a follow-up time window.

[0039] As an improvement to this application, the execution distribution module includes parsing the permission action into an execution task and sending it to the outpatient terminal, the system terminal, and the doctor terminal;

[0040] After receiving the corresponding execution task, the outpatient terminal is responsible for showing, explaining and recording the start time of the execution plan to the patient;

[0041] The system terminal is used to distribute tasks to the home terminal and establish reminder and feedback channels;

[0042] The doctor's side includes additional risk indicators and rollback trigger conditions for monitoring.

[0043] As an improvement to this application, when an unexpected event occurs in the home terminal feedback, the current pending queue is paused and the feedback module is activated for monitoring;

[0044] When the unexpected event reaches a preset threshold, a conservative strategy is implemented and the doctor is notified simultaneously.

[0045] As an improvement to this application, if the doctor determines that the current action chain has an unacceptable risk, the log management module will roll back the patient's plan to the most recent stable plan snapshot.

[0046] During rollback, the log management module shall record at least: the target version to be rolled back, the reason for rollback, the trigger source, the execution time, whether it was automatically triggered by the system, whether the doctor provided additional confirmation, and the observation window after the rollback;

[0047] If no stable snapshot exists, revert to the last confirmed and executed conservative version.

[0048] As an improvement to this application, the log management membrane module also records the chain of responsibility data for any patient and the corresponding candidate action.

[0049] The beneficial effects of this invention are as follows: Compared with the prior art, the safety gating system for personalized medication dispensing for Parkinson's disease provided by this invention completes the template processing and version consistency verification of candidate action packages through the version anchoring module, and preemptively identifies risks such as mismatched protocol snapshots and lack of stable rollback protocols. Then, combined with the safety constraint screening module, it completes the initial risk screening. After the risk grading module classifies different risk levels, it is handed over to the doctor for grading confirmation, then issued for execution and feedback is received. Finally, the log management module completes the process recording and anomaly handling. It integrates candidate medication dispensing actions, protocol snapshot management, stable protocol anchoring, anomaly rollback, and audit responsibility chain into the complete workflow of Parkinson's disease medication dispensing. It is specifically adapted to the medication dispensing scenario of Parkinson's disease, which can effectively improve the safety of the personalized medication dispensing process, realize the traceability and controllability of the entire medication dispensing process, and solve the problem of insufficient integration in the prior art. Attached Figure Description

[0050] Figure 1 This is a system framework diagram of the present invention. Detailed Implementation

[0051] To more clearly illustrate the present invention, the invention will be further described below with reference to the accompanying drawings.

[0052] In the following description, specific examples are given to provide a more in-depth understanding of the invention. It is obvious that the described embodiments are merely some, not all, of the embodiments of the invention. It should be understood that the specific embodiments described are for illustrative purposes only and are not intended to limit the scope of the invention.

[0053] It should be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of the said feature, integral, step, operation, element, or component, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, or combinations thereof.

[0054] As a general premise, the security gating in this application should be understood as: a mandatory inspection and restriction mechanism set manually or by the system during the process of drug adjustment (adding, reducing, or changing medication) to prevent erroneous decisions from causing harm to the patient.

[0055] To address the aforementioned technical problems, this application provides a safety gating system for personalized medication administration in Parkinson's disease. Please refer to the appendix. Figure 1 It includes: candidate action input module, version anchoring module, safety constraint filtering module, risk classification module, doctor processing module, execution module, feedback module and log management module;

[0056] The candidate action input module is used to create a drug dispensing execution session and connect to the project interface; the project interface includes current observation parameters, current confirmed protocol snapshots, protocol snapshots, and candidate action packages.

[0057] The version anchoring module is used to perform template processing and version consistency verification on candidate action packages;

[0058] The safety constraint filtering module is used to filter candidate actions based on safety constraint rules;

[0059] The risk classification module performs risk classification based on risk, confidence level, and anomaly indicators;

[0060] The doctor's processing module confirms the action to be performed based on the risk level result;

[0061] The execution and distribution module is used to generate execution tasks and distribute them to the outpatient and home care terminals after the doctor confirms them;

[0062] The feedback module is used to receive feedback on execution confirmation, non-execution, delayed execution, and exceptions.

[0063] The log management module executes freeze, upgrade review, or rollback to a stable solution based on the feedback results, and records the corresponding audit logs and writes back the results.

[0064] It's easy to understand that the version anchoring module completes the templated processing and version consistency verification of candidate action packages, proactively identifying risks such as mismatched solution snapshots and the lack of stable rollback solutions. Combined with the safety constraint screening module, initial risk screening is performed. After the risk grading module classifies different risk levels, it is handed over to doctors for grading confirmation, then issued for execution and feedback is received. Finally, the log management module completes process recording and anomaly handling. This integrates candidate medication dispensing actions, solution snapshot management, stable solution anchoring, anomaly rollback, and audit responsibility chain into a complete workflow for Parkinson's disease medication dispensing. Specifically adapted to the medication dispensing scenario for Parkinson's disease, it effectively improves the safety of individualized medication dispensing, achieves traceability and controllability throughout the entire dispensing process, and solves the problem of insufficient integration in existing technologies.

[0065] As an improvement to this application, the candidate action package is encapsulated from candidate medication dispensing actions. After encapsulating candidate medication dispensing actions into a unified candidate action package, overall version verification and risk control can be performed on all adjustments in a single medication dispensing, avoiding logical conflicts or verification omissions that may occur when processing independent actions, and ensuring the integrity and consistency of the medication dispensing plan. Correspondingly, the candidate action package content includes at least: patient identifier, session identifier, candidate action number, candidate action source, input observation information version, currently confirmed plan snapshot number, associated stable plan snapshot identifier, target drug or drug template identifier, proposed adjustment of dose / single dose / administration time / administration frequency field, action type, action reason, risk warning, source credibility or confidence level, action effective time window, suggested monitoring window, and preset review level. The source of the medication dispensing action can be the output of the PF-01 dynamic decision engine, candidates manually entered by the doctor, hospital protocol templates, remote review suggestions, or review candidates triggered by the follow-up terminal. It should be noted that this invention does not focus on generating the optimal action ranking itself as its core protected object, but rather on the processing mechanism after candidate actions enter the security gating screening and execution workflow. In specific applications, when outpatient follow-up visits, system-preset review times arrive, patients report abnormal events, home summary shows significant deviations, or doctors initiate reviews, the system creates a medication dispensing execution session. The session box is bound to at least the patient identifier, the snapshot of the currently confirmed protocol, the snapshot of the most recently stable protocol, the source of the candidate action, and the current observation information version. Regarding the source of candidate actions, this invention can receive candidate actions from the PF-01 dynamic decision engine, as well as candidate actions manually entered by doctors, guideline templates, hospital protocol templates, or remote review suggestions, as long as these actions are encapsulated into auditable candidate action packages and enter the workflow defined by this invention before entering the execution layer.

[0066] Specifically, the version anchoring module, in terms of template processing, includes the following steps:

[0067] A1. Obtain candidate action packages and map them to standardized fields using a unified mapping based on the external decision engine; check if the standardized fields are complete, and review or disable candidate action packages with missing fields;

[0068] The version anchoring module includes the following steps in version consistency verification:

[0069] A2. Obtain candidate action packages and verify whether the snapshot of the solution confirmed by the candidate action package is equal to the specified solution snapshot in the system; if not, check whether there are any high-risk preceding actions that have not been closed or whether the most recent execution result has not yet entered the evaluation window, and then preferably freeze the new action and enter the upgrade review; if so, check whether there are other available solution snapshots.

[0070] It's easy to understand that in step A1, the standardized fields are: action type, target drug, step size, single dose template, dosing time template, dosing frequency template, and effective time window. The system checks whether these standardized fields are complete; if a candidate action package lacks a key field, it is directly marked as requiring manual review or prohibited. Standardizing actions facilitates subsequent risk screening and grading, avoiding rule matching failures due to inconsistent formats and ensuring the integrity of safety constraint verification. The implementation of the protocol snapshot can be achieved using a local database, server database, versioned configuration files, or secure storage units.

[0071] In step A2, a protocol snapshot refers to a protocol that has been confirmed by the physician, actually implemented by the patient, and has achieved a basically acceptable effect without any unacceptable adverse reactions within the preset minimum retention time. A stable protocol snapshot includes at least: a snapshot identifier, drug composition, dosage / time / frequency fields, formation time, minimum retention time, rollback flag, rollback lock duration, and the most recent valid observation summary. Version consistency verification of protocol snapshots can detect version conflicts that occur during protocol iteration in advance. When there are high-risk actions that are not closed in time, new actions are frozen first to avoid the accumulation of risks, ensuring that each medication adjustment is based on a stable protocol that has been evaluated, thus reducing the risk of medication adjustment from the source. On the other hand, for risk classification methods, explicit rule tables, hierarchical scoring models, confidence estimation models, Bayesian risk updates, or combinations thereof can be used. As long as the system can classify candidate actions as prohibited, low-risk, medium-risk, and high-risk based on safety constraints, data integrity, and execution context, and decide whether to allow them to enter the execution stage accordingly.

[0072] Specifically, the screening steps of the security constraint screening module include:

[0073] Generate filter items;

[0074] A3. Check whether the selected action package meets the selection criteria. If it does, the candidate action violates the constraints. Record the reason for the block and mark it as prohibited. If not, generate a corresponding risk level for the candidate action.

[0075] It's easy to understand that the screening criteria include: whether a single dose adjustment exceeds the maximum single adjustment step size threshold; whether the current candidate action is within the minimum review interval threshold since the last confirmed high-impact medication adjustment; whether it triggers prohibited drug combinations, repeated conflicting actions, or disallowed synergistic action templates; whether the patient has cognitive / psychiatric red flags, significant hallucinations / psychosis risk, severe somnolence, orthostatic hypotension, or recent serious adverse reactions; whether compliance is interrupted or there are key execution gaps; whether key observation information is missing, conflicting, or exceeds the acceptable time window; whether the candidate action package version is mismatched; and whether there are mutually exclusive actions or incomplete high-risk actions in the current execution queue. Therefore, by classifying the risk of the screened candidate actions, the system can categorize actions into different risk levels by combining action type, patient's current state, candidate source credibility, completeness of observation information, and version stability. Actions with a significant impact on the patient are treated as hard constraints. If a candidate action violates a hard constraint, the system records the reason for interception and marks it as prohibited. If a candidate action does not violate a hard constraint but has significant uncertainty, the system will raise its risk level by at least one level.

[0076] In the specific scheme, the risk classification module responds to the risk level to generate four levels, including a first level, a second level, a third level, and a fourth level, each with corresponding execution actions. Specifically, the first level is considered low risk, the second level medium risk, the third level high risk, and the fourth level prohibited. The corresponding execution actions for each level are as follows:

[0077] The first level of execution actions are: maintaining the current plan, suspending execution within the doctor's preset boundaries, or reverting to the action triggered by a specific event;

[0078] The second level of execution actions are: adjusting the dosage within a preset step size; such as adding or subtracting medication, adjusting the single dose, adjusting the timing of administration, and adjusting the frequency of administration.

[0079] The third level of actions includes: drug switching, changes in medication on preset quantity items and dosage changes under red flag conditions, version conflicts of snapshot protocols, addition or subtraction of adjuvant drugs, drug switching, actions related to advanced therapies, actions with low confidence and high impact, and actions with insufficient key data.

[0080] The action for the fourth level is: entry is not permitted.

[0081] It's easy to understand that dividing actions into four different risk levels, corresponding to different levels of physician confirmation requirements, ensures medication dispensing safety while reducing redundancy in low-risk dispensing processes, improving overall efficiency, adapting to different scenarios, and avoiding the slowdown of treatment by indiscriminate manual approval. Furthermore, actions are routed to automatic conservative processing, physician confirmation, or manual escalation review based on risk level. It's evident that actions selected for execution enter risk-based processing. The system comprehensively considers action type, patient's current status, candidate source credibility, observation information completeness, and version stability, effectively optimizing physician intervention. For example, for high-risk and low-confidence actions, it's preferable not to execute them directly, but instead output conservative processing suggestions such as "postponing execution, escalating to manual review, or reverting to a stable plan."

[0082] In this embodiment, the doctor processing module is used to generate corresponding confirmation and permission actions for different risk levels; wherein:

[0083] For Level 1 permission actions, this includes whether to allow the execution of actions that can be confirmed in batches or individually;

[0084] The permitted actions for Level 2 include: confirming each item and setting monitoring points;

[0085] The third-level permission actions include: case confirmation interface, recording the reason for confirmation, explanation of exceptions, whether automatic rollback is allowed, and follow-up time window;

[0086] Even better, if the doctor believes that the current information is insufficient, the action can be set to "suspend execution" or "upgrade to manual review";

[0087] In this embodiment, the doctor processing module will release the corresponding medication dispensing action according to the doctor's confirmation and permission instruction. Medication dispensing actions that meet the release conditions will proceed to the next step, while actions that do not meet the release conditions or are blocked will be rolled back to the original stable plan as required by the doctor, or enter the manual review process for further processing. The entire gating process, from action screening to risk classification to doctor confirmation, forms a complete closed-loop control, which simplifies the process burden of routine medication dispensing to the greatest extent while ensuring the safety of individualized medication dispensing, and adapts to the actual needs of long-term medication management for Parkinson's disease patients. It is worth noting that the rollback trigger threshold can be implemented using explicit rules, exception event tables, doctor confirmation trigger conditions, or a combination of conditions.

[0088] In this embodiment, the execution delivery module includes parsing the permission action into an execution task and sending it to the outpatient terminal, the system terminal, and the doctor terminal;

[0089] After receiving the corresponding execution task, the outpatient department is responsible for showing, explaining and recording the start time of the execution plan to the patient;

[0090] The system is used to distribute tasks to the home end and establish reminder and feedback channels;

[0091] Additional risk indicators and rollback trigger conditions are added for doctors to monitor.

[0092] It's easy to understand that after receiving the task at home, the system will push medication adjustment reminders according to the doctor's orders, regularly collect feedback information such as changes in the patient's symptoms and medication reactions, and simultaneously send it back to the system for processing and summarization. If the patient experiences an abnormal reaction that meets the preset rollback trigger conditions during home medication use, the system will automatically trigger the rollback mechanism, switching back to the original stable medication plan, and immediately push an abnormality warning to the doctor, reminding the doctor to follow up and assess the situation in a timely manner. The entire execution and distribution process connects multiple nodes, including outpatient clinics, doctors, the system, and home-based patients, achieving a seamless end-to-end connection between medication adjustment plan confirmation and home-based execution monitoring, ensuring that the entire medication adjustment process is controllable. In a more specific scenario, if the task has a phased structure, the system will simultaneously issue conditional tasks for subsequent phases, but will not automatically release them until the conditions are met. It is worth noting that for the home-based time mode, patient mobile applications, SMS / telephone interaction terminals, in-hospital patient portals, home follow-up devices, or other remote interaction carriers can be used; for the outpatient and doctor terminals, embedded interfaces of electronic medical records, independent review terminals, or in-hospital collaborative terminals can also be used. As long as the system can complete the closed loop of confirmation, issuance, execution and feedback, it will not affect the establishment of this invention.

[0093] In a further proposed solution, when an unexpected event is reported from the home end, the current pending queue is paused and the feedback module is activated for monitoring.

[0094] When an unexpected event reaches a preset threshold, a conservative strategy is implemented and the doctor is notified simultaneously.

[0095] For abnormal fluctuations that do not reach the preset trigger threshold, the system will maintain the current medication adjustment progress and only synchronously annotate and summarize the fluctuation data to the doctor's end. After receiving the information, the doctor can independently determine whether early intervention is needed. This avoids excessive intervention in the normal medication adjustment process and allows the doctor to keep abreast of subtle changes in the patient's condition. In a further solution, corresponding task progress can be set. When the patient at home completes all monitoring tasks for the current stage as required and all indicators meet the stage's target requirements, the system will automatically unlock and release the medication adjustment task for the next stage to continue the medication adjustment process.

[0096] Furthermore, if the doctor's end determines that there are unacceptable risks in the current action chain, the log management module will roll back the patient's plan to the most recent stable plan snapshot. When rolling back, the log management module records at least: the rollback target version, the rollback reason, the trigger source, the execution time, whether it is automatically triggered by the system, whether the doctor makes a supplementary confirmation, and the observation window after the rollback. If there is no stable plan snapshot, it will be rolled back to the previous conservative version that has been confirmed and executed.

[0097] Through conditional triggering, phased unlocking, exception grading response, and traceable rollback mechanism, combined with the data linkage between outpatient orders and home monitoring, this system not only ensures that the medication adjustment process of Parkinson's disease patients can be steadily advanced according to individualized plans, but also avoids the health risks caused by improper medication adjustment through multi-level risk control. At the same time, it realizes the traceable management of the entire medication adjustment process, helps doctors dynamically grasp the state changes of patients during medication adjustment, and improves the safety and controllability of individualized medication adjustment.

[0098] Furthermore, the log management module also correspondingly records the responsibility chain of any patient and the corresponding candidate actions.

[0099] This responsibility chain will completely record the responsible entities and operation records of each link in the whole process from the generation of candidate medication adjustment actions, automatic gate control preliminary review, doctor's end review and confirmation to final execution and monitoring feedback. Once abnormalities or disputes occur during the subsequent medication adjustment process, the responsible link and person can be quickly traced and located through the responsibility chain, providing a complete and traceable original basis for the optimization of the subsequent medication adjustment plan and the definition of medical responsibilities. At the same time, the responsibility chain record will be updated and archived synchronously with each medication adjustment action, and is associated with the patient's plan version snapshot and rollback log to form a complete closed-loop file for the whole life cycle of the patient's individualized medication adjustment. For example, the system makes structured traces of the whole conversation process, including candidate action packages, version consistency results, screening results, risk levels, doctor confirmations, execution tasks, patient execution status, exception feedback, escalation review, and rollback events. Through this log chain, the whole process of any action from "who proposed - who confirmed - who issued - who executed - who feedback" to "when frozen - when rolled back - why rolled back" can be traced back.

[0100] As a preferred embodiment, different permission parameters are set for the home terminal, doctor terminal, outpatient terminal, and system terminal. For example, the outpatient terminal preferably has permissions for version verification, plan display, and start recording; the doctor terminal preferably has permissions for confirming, rejecting, suspending, upgrading, and rolling back permissions; the system terminal preferably has permissions for status transition, queue management, freezing, and log writing; and the home terminal preferably has permissions for receiving confirmation, recording actual execution, and providing anomaly feedback. More preferably, the remote terminal or patient terminal must not bypass doctor confirmation to directly write high-risk execution actions. Therefore, high-risk medication dispensing actions must be manually reviewed by the doctor before entering the execution stage, thus strengthening the first line of defense for medication dispensing security at the permission level. Under this hierarchical permission framework, each terminal can only complete corresponding operations within its own permission scope. This ensures the independence and convenience of operations for different roles, avoids medical risks caused by unauthorized operations through permission isolation, and also corresponds to the entire process responsibility chain. Every permission operation will be automatically recorded and archived, ensuring the compliance and traceability of the entire medication dispensing process.

[0101] In this embodiment, a data write-back module is also included. The data write-back module writes the execution results after the closed loop back to the system for subsequent V1 safety replay, V2 physician-in-the-loop workflow pilot, and V3 prospective workflow validation. The write-back content preferably includes the final execution status, monitoring results, abnormal event labels, rollback results, and specific data streams of the physician processing module.

[0102] The advantages of this invention are:

[0103] 1) This invention is not limited to outputting medication dispensing suggestions, but integrates candidate action package access, version consistency verification, security screening, risk classification, doctor confirmation, execution and distribution, home feedback and freeze / rollback into the same state machine, thereby truly transforming medication dispensing suggestions into executable clinic-home clinical processes.

[0104] 2) This invention compresses execution layer actions into a limited, auditable, and rollbackable action type, and establishes a unified anchor point through candidate action number, current solution version, and stable solution snapshot, thus making it easier to form a standardized candidate action governance chain.

[0105] 3) This invention distinguishes which actions can be used as system ranking candidates, which actions must be confirmed by doctors, which actions can only be performed under specific conditions, and which actions should be directly blocked by clearly defined automation boundaries, so that automation will not cross the bottom line of clinical safety.

[0106] 4) This invention establishes a clear division of responsibilities among the outpatient end, doctor end, system end, and home end, and provides specific processing logic for execution confirmation, non-execution, delayed execution, and abnormal feedback, solving the problems of existing systems such as "no one tracks after the suggestion is issued, home execution is not visible, and abnormal event response is delayed".

[0107] 5) This invention enables the system to prioritize conservative strategies and promptly stop the spread of risks and return to a confirmed safe state in the event of side effects, abnormal compliance, worsening symptoms, missing key data, version mismatch, or low confidence, through the construction, execution strategy, and rollback mechanism of the solution snapshot.

[0108] The above-disclosed embodiments are merely a few specific examples of the present invention, but the present invention is not limited thereto. Any variations that can be conceived by those skilled in the art should fall within the protection scope of the present invention.

Claims

1. A safety gating system for personalized medication administration in Parkinson's disease, characterized in that, It includes: candidate action input module, version anchoring module, safety constraint filtering module, risk classification module, doctor processing module, execution module, feedback module, and log management module; The candidate action input module is used to create a medication dispensing execution session and connect to the project interface; the project interface includes current observation parameters, currently confirmed protocol snapshots, protocol snapshots, and candidate action packages. The version anchoring module is used to perform template processing and version consistency verification on the candidate action package; The security constraint filtering module is used to perform candidate action filtering based on security constraint rules; The risk classification module performs risk classification based on risk, confidence level, and anomaly indicators; The doctor processing module confirms the action to be performed based on the result of the risk level; The execution and distribution module is used to generate execution tasks and distribute them to the outpatient and home terminals after the doctor confirms them. The feedback module is used to receive feedback on execution confirmation, non-execution, delayed execution, and exceptions. The log management module performs freeze, upgrade review, or rollback to a stable solution based on the feedback results, and records the corresponding audit logs and writes back the results.

2. The safety gating system for personalized medication administration in Parkinson's disease according to claim 1, characterized in that, The candidate action package is obtained by encapsulating the candidate drug dispensing action.

3. A safety gating system for personalized medication administration in Parkinson's disease according to claim 1, characterized in that, The templated processing includes: The candidate action package is obtained and mapped to standardized fields using a unified method based on an external decision engine; Check if the standardized fields are complete, and review or disable candidate action packages with missing fields; The version consistency check includes: Obtain the candidate action package and verify whether the solution snapshot confirmed by the candidate action package is equal to the specified solution snapshot in the system; If not, the system will check whether there are any high-risk preceding actions that have not been closed, or whether the result of the most recent execution has not yet entered the evaluation window. If so, the system will prefer to freeze the new action and proceed to the upgrade review. If so, check if there is a usable solution snapshot.

4. A safety gating system for personalized medication administration in Parkinson's disease according to claim 1, characterized in that, The screening steps of the security constraint screening module include: Generate filter items; The selected action package is checked to see if it meets the selection criteria. If it does, the candidate action violates the constraint criteria, the reason for blocking is recorded and it is marked as prohibited. If not, a corresponding risk level is generated for the candidate action.

5. A safety gating system for personalized medication administration in Parkinson's disease according to claim 4, characterized in that, The risk classification module responds to the risk level to generate a first level, a second level, a third level, and a fourth level, each with a corresponding action to be performed. The first level of execution actions are: maintaining the current plan, suspending execution within the doctor's preset boundaries, or reverting to a plan triggered by a specific event; The second level of execution action is: to adjust the dosage of the drug within a preset step size; The actions performed at the third level are: drug switching, changes in medication on preset quantity items, and dosage changes under the red flag state; The action to be taken at the fourth level is: do not allow entry for execution.

6. A safety gating system for personalized medication administration in Parkinson's disease according to claim 1, characterized in that, The doctor processing module is used to generate corresponding confirmation and authorization actions for different risks and other actions. in Confirmed: The permission actions for the first level include whether to allow the execution of batch confirmation or single confirmation actions; The permitted actions for the second level include: confirming each item and setting monitoring points; The permission actions for the third level include: a case confirmation interface that records the confirmation reason, exception explanation, whether automatic rollback is allowed, and a follow-up time window.

7. A safety gating system for personalized medication administration in Parkinson's disease according to claim 1, characterized in that, The execution delivery module includes parsing the permission action into an execution task and sending it to the outpatient terminal, the system terminal, and the doctor terminal; After receiving the corresponding execution task, the outpatient terminal is responsible for showing, explaining and recording the start time of the execution plan to the patient; The system terminal is used to distribute tasks to the home terminal and establish reminder and feedback channels; The doctor's side includes additional risk indicators and rollback trigger conditions for monitoring.

8. A safety gating system for personalized medication administration in Parkinson's disease according to claim 7, characterized in that, When an unexpected event is reported from the home terminal, the current pending queue is paused and the feedback module is activated for monitoring. When the unexpected event reaches a preset threshold, a conservative strategy is implemented and the doctor is notified simultaneously.

9. A safety gating system for personalized medication administration in Parkinson's disease according to claim 8, characterized in that, If the doctor determines that the current action chain has an unacceptable risk, the log management module will roll back the patient's plan to the most recent stable plan snapshot. During rollback, the log management module shall record at least: the target version to be rolled back, the reason for rollback, the trigger source, the execution time, whether it was automatically triggered by the system, whether the doctor provided additional confirmation, and the observation window after the rollback; If no stable snapshot exists, revert to the last confirmed and executed conservative version.

10. A safety gating system for personalized medication administration in Parkinson's disease according to claim 9, characterized in that, The log management module also records the chain of responsibility data for each patient and the corresponding candidate action.

Images