Intelligent peritoneal dialysis for kidney disease full life cycle management system and method

Abstract

This invention relates to the field of medical information management technology, and discloses an intelligent peritoneal dialysis full lifecycle management system and method for kidney disease, comprising: a patient registration module for generating a unique patient identifier and a current prescription cycle management unit; an event aggregation module for generating a current prescription cycle event set; a closed-loop construction module for generating a set of closed-loop treatment units for the current prescription cycle; a break determination module for determining break type labels; a task generation module for generating repair task packages; a state convergence module for determining the closed-loop treatment unit repair results, cycle convergence degree, cycle instability, and current prescription cycle state; and a cycle inheritance module for generating the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full lifecycle state chain. This invention achieves unified organization of multi-source data, accurate identification of broken links, and continuous connection of subsequent treatments throughout the entire lifecycle of home-based peritoneal dialysis.

Description

Technical Field

[0001] This invention belongs to the field of medical information management technology, specifically relating to an intelligent management system and method for the entire life cycle of peritoneal dialysis for kidney disease. Background Technology

[0002] Peritoneal dialysis is a common home-based replacement therapy for kidney disease patients. Its treatment process is characterized by high frequency of outpatient procedures, long duration, and repeated prescription adjustments and follow-up interventions. Unlike one-time medical visits or routine chronic disease follow-ups, peritoneal dialysis management involves not only current effective prescriptions but also various other information such as equipment execution records, patient self-reporting, vital sign monitoring, laboratory test results, medical and nursing interventions, and alert responses. This information occurs continuously over time and is interconnected in terms of procedures.

[0003] In existing technologies, peritoneal dialysis management is often conducted through single follow-up visits, single-item monitoring, or decentralized modules. Prescriptions, equipment logs, patient feedback, training records, and medical intervention records are often stored in different systems or functional modules, lacking a unified cycle boundary and a continuous management thread. This makes it difficult to aggregate multi-source data for correlation analysis within the same treatment cycle, and also makes it difficult to form a complete execution, feedback, and treatment chain around specific treatment actions. In long-term outpatient treatment scenarios, if patients have execution deviations, missing feedback, or delayed medical responses, existing methods can usually only detect single abnormalities, making it difficult to further determine which link in the treatment chain the problem occurs at. This can easily lead to unclear responsibility, untimely intervention, duplicate processing, and lack of process traceability. Summary of the Invention

[0004] This invention provides an intelligent peritoneal dialysis full life cycle management system and method for renal disease, which solves the technical problems in related technologies where prescriptions, equipment execution, patient reporting, vital sign monitoring, laboratory tests and medical care are scattered and difficult to collect uniformly according to the same treatment cycle during the long-term home management of peritoneal dialysis. This leads to the inability to accurately identify the broken links in the treatment closed loop, and thus easily results in unclear responsibilities, delayed intervention, duplicate processing and difficulty in continuous traceability of the whole process.

[0005] This invention provides an intelligent peritoneal dialysis full life cycle management system for kidney disease, comprising: The patient registration module is used to obtain patient identity information, current valid dialysis prescriptions, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; The event aggregation module is used to acquire peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and to generate the current prescription cycle event set based on the current prescription cycle management unit; The closed-loop construction module is used to generate a set of closed-loop treatment units for the current prescription cycle based on the event set and prescription regulations of the current prescription cycle. The fracture determination module is used to determine the fracture type label based on the current prescription cycle closed-loop treatment unit set, preset execution deviation determination threshold, preset feedback deviation determination threshold, and preset response deviation determination threshold. The task generation module is used to generate repair task packages based on the correspondence between fracture type labels and preset treatment paths. The repair task packages include training repair task packages, medical review task packages, upgrade transfer task packages, or composite treatment task packages. The state convergence module is used to determine the closed-loop treatment unit repair result, cycle convergence, cycle instability and current prescription cycle state based on the execution result of the repair task package and the current prescription cycle closed-loop treatment unit set; The cycle inheritance module is used to generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle state chain based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results.

[0006] This invention also provides an intelligent method for the full life-cycle management of peritoneal dialysis for kidney disease, comprising the following steps: Step 81: Obtain patient identity information, current valid dialysis prescription, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; Step 82: Obtain peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and generate the current prescription cycle event set based on the current prescription cycle management unit; Step 83: Generate a set of closed-loop treatment units for the current prescription cycle based on the event set of the current prescription cycle and the actions to be performed according to the prescription. Step 84: Determine the breakage type label based on the current prescription cycle closed-loop treatment unit set, the preset execution deviation judgment threshold, the preset feedback deviation judgment threshold, and the preset response deviation judgment threshold; Step 85: Generate a repair task package based on the correspondence between the fracture type label and the preset treatment path. The repair task package includes a training repair task package, a medical review task package, an upgrade transfer task package, or a composite treatment task package. Step 86: Based on the execution results of the repair task package and the current prescription cycle closed-loop treatment unit set, determine the closed-loop treatment unit repair results, cycle convergence, cycle instability, and current prescription cycle status. Step 87: Based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results, generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle status chain.

[0007] The beneficial effects of this invention are as follows: This invention uses the prescription cycle as the main management line, unifying various data such as patient registration information, peritoneal dialysis equipment execution records, patient reports, vital sign monitoring, laboratory tests, training questionnaires, and medical staff observations and treatments into a single cycle. This reduces the problems of data dispersion, unclear attribution, and chaotic time boundaries during outpatient treatment. By constructing closed-loop treatment units around individual prescription actions and separately judging the execution, feedback, and response stages, the invention can more accurately locate the break points in the treatment chain, avoiding general judgments based solely on single abnormalities. Furthermore, this invention maps different break types to treatment paths such as training repair, medical staff review, and escalation transfer, which helps improve the targeting and continuity of interventions. Simultaneously, this invention can generate inheritance strategies for the next cycle based on the repair results and cycle status of the current cycle, forming a continuous management relationship between cycles, thereby improving the continuity, traceability, and collaborative processing effect of long-term home management of peritoneal dialysis. Attached Figure Description

[0008] Figure 1 This is a schematic diagram of a module of an intelligent peritoneal dialysis full life cycle management system for kidney disease according to the present invention. Detailed Implementation

[0009] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, features described in some examples may be combined in other examples.

[0010] like Figure 1 As shown, an intelligent peritoneal dialysis full life cycle management system for kidney disease includes: The patient registration module is used to obtain patient identity information, current valid dialysis prescriptions, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; The event aggregation module is used to acquire peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and to generate the current prescription cycle event set based on the current prescription cycle management unit; The closed-loop construction module is used to generate a set of closed-loop treatment units for the current prescription cycle based on the event set and prescription regulations of the current prescription cycle. The fracture determination module is used to determine the fracture type label based on the current prescription cycle closed-loop treatment unit set, preset execution deviation determination threshold, preset feedback deviation determination threshold, and preset response deviation determination threshold. The task generation module is used to generate repair task packages based on the correspondence between fracture type labels and preset treatment paths. The repair task packages include training repair task packages, medical review task packages, upgrade transfer task packages, or composite treatment task packages. The state convergence module is used to determine the closed-loop treatment unit repair result, cycle convergence, cycle instability and current prescription cycle state based on the execution result of the repair task package and the current prescription cycle closed-loop treatment unit set; The cycle inheritance module is used to generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle state chain based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results.

[0011] In one embodiment of the present invention, the system acquires patient identity information, currently valid dialysis prescription, prescription start time, prescription end time, responsible medical team, prescribed execution actions, and prescription feedback items, and generates a unique patient identifier and a current prescription cycle management unit accordingly. The currently valid dialysis prescription represents the medical order that is currently in effect and is actually used to guide the patient in home peritoneal dialysis treatment, and may include dialysis method, exchange frequency, infusion volume, retention time, ultrafiltration target, and associated monitoring requirements. The responsible medical team refers to the doctor, nurse, or management team responsible for follow-up, review, intervention, and result confirmation during the prescription cycle. Prescription execution actions represent the dialysis operations, reporting operations, or confirmation operations that the patient needs to complete during the cycle. Prescription feedback items represent data items used to reflect treatment execution and the patient's physical condition, and may include weight, blood pressure, ultrafiltration volume, drainage status, symptom records, or test results, etc.

[0012] Before a patient enters the home management process, the system first verifies the basic data and then forms a unified periodic management object. This ensures that subsequent device records, patient reports, vital sign monitoring, and medical care treatment all fall within the same treatment cycle, and that subsequent closed-loop judgments are based on consistent data boundaries, rather than on scattered and fragmented records.

[0013] In step 11, the system first performs an integrity check on the patient's identity information, the currently valid dialysis prescription, the prescription's effective start time, the prescription's effective end time, the responsible medical team, the prescribed actions, and the prescription's feedback requirements. It then verifies that all information is present and not empty. This integrity check goes beyond simply checking if data has been uploaded; it also includes verifying the completeness of key fields relied upon for subsequent management. For example, patient identity information may include name, medical record number, contact information, hospital number, or the hospital's master index information; the dialysis prescription may include the dialysis mode and execution requirements for the current cycle; and the feedback items may include the monitoring and reporting items required for the current cycle.

[0014] If any item is missing, the system will not directly generate the current prescription cycle management unit, but will instead retain it as pending completion. For example, if a patient has already entered a dialysis prescription and assigned a responsible medical team, but has not configured the blood pressure, weight, and drainage status required for this cycle, the system can determine that the data set does not yet meet the cycle establishment conditions. After this processing, subsequent data entering the system will not be incorrectly assigned to a prescription cycle due to incomplete initial conditions.

[0015] In step 12, the system performs a time-series check on the prescription's effective start and end times to determine if the prescription's effective end time is later than the prescription's effective start time. This time-series check determines whether the cycle has clear time boundaries, facilitating the subsequent limitation of equipment logs, patient reports, test results, and medical treatment records to the same time range. If the start time is later than the end time, or if the time range does not meet the preset management requirements, the cycle cannot be used as a valid management cycle.

[0016] After completing the time-series verification, the system continues to verify the correspondence between the responsible medical team, the prescribed actions, and the prescription feedback items. This correspondence verification confirms the management responsibility binding relationship between the responsible medical team and the currently valid dialysis prescription, and confirms that the prescribed actions and prescription feedback items originate from the currently valid dialysis prescription, and not from historical prescriptions, other patient templates, or irrelevant temporarily entered items. In other words, the system not only verifies the existence of data, but also verifies whether this data belongs to this patient, this prescription, and this time period. For example, if the current prescription is for nighttime automated peritoneal dialysis, but the actions include daytime manual fluid changes, the system can determine that the action source is inconsistent. Similarly, if the feedback items contain content that is not required by the current prescription, the system can also prevent that cycle from being mistakenly created.

[0017] In step 13, the system standardizes the patient identity information that has undergone integrity verification, timing verification, and correspondence verification, and generates a unique code based on the standardized patient identity information. This unique code serves as the patient's unique identifier. Standardization here means uniformly organizing, mapping, and deduplicating identity fields from different sources and in different formats to ensure consistency in the representation of the same patient within the system. For example, the same patient may have different writing styles on the device, follow-up, and testing ends; the system can unify these information under a single standard patient entity. The unique code represents a machine-readable identifier used within the system to uniquely identify the patient's treatment subject, and can be generated based on the hospital's master index, rule-based coding, or desensitized mapping results.

[0018] Subsequently, the system binds the patient's unique identifier, the currently valid dialysis prescription, the prescription's effective start time, the prescription's effective end time, the responsible medical team, the prescribed actions, and the prescription's required feedback items to generate a current prescription cycle management unit. The current prescription cycle management unit represents a basic management object established with the treatment activities of a specific patient within the validity period of a specific prescription as its boundary. It is used to receive subsequent execution records, vital sign records, test results, training records, reminder records, and medical and nursing treatment records occurring within that cycle. The patient's unique identifier primarily addresses patient attribution, while the current prescription cycle management unit further determines what the patient should perform, what feedback should be provided, and who is responsible for management within the current prescription cycle.

[0019] After this embodiment is completed, the system first organizes the patient information, prescription cycle, responsible medical staff, and execution feedback requirements into a unified data foundation before proceeding to the subsequent event aggregation and closed-loop analysis stages. This reduces data mismatches caused by inconsistent patient identification, unclear prescription cycle boundaries, or ambiguous responsible parties, and also ensures that subsequent home treatment records, remote monitoring data, and medical intervention information are continuously organized around the same cycle. For long-term outpatient treatment scenarios such as peritoneal dialysis, this approach helps improve the continuity, traceability, and consistency of treatment process records, making the system's patient management, treatment execution, and remote collaborative processing more closely aligned with actual medical management needs.

[0020] In one embodiment of the present invention, the system acquires peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and generates a current prescription cycle event set based on the current prescription cycle management unit. The peritoneal dialysis equipment execution records here represent the operation logs, treatment parameters, alarm information, or execution results generated during the operation of the peritoneal dialysis equipment; the patient manual reporting records represent symptoms, physical sensations, abnormal descriptions, or treatment confirmation information actively entered by patients or caregivers through the patient terminal; the vital signs monitoring records represent home monitoring data such as blood pressure, weight, body temperature, and heart rate; the laboratory test results represent laboratory indicators, test conclusions, or test values ​​generated in or outside the hospital; the patient training and questionnaire records represent records generated when patients receive operation training, watch learning materials, complete assessment questionnaires, or submit training feedback; the medical staff viewing and handling records represent business records generated when medical staff view, review, remind, guide, or intervene in patient data; and the reminder sending and response records represent pending tasks, reminders, and follow-ups sent by the system to patients or medical staff, as well as the corresponding receipt, confirmation, and feedback.

[0021] The current prescription cycle event set represents the set of all valid events related to the treatment activities of the same patient within the same prescription effective cycle. This event set is not a simple stacking of raw data, but rather a standardized set of event inputs that unifies records from different sources, with different structures, and different time granularities and can be used for subsequent closed-loop analysis.

[0022] In step 21, the system first aggregates the peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical staff observation and treatment records, and reminder sending and response records. Aggregation means unifying the raw records from different system interfaces, different input ports, and different storage locations into the same processing flow, rather than allowing various records to be scattered and retained in their respective sub-modules for a long time. For each aggregated record, the system extracts the patient attribution information, record occurrence time, source category, and data content, and writes this content into a single standardized record.

[0023] The patient attribution information indicates the source of the patient's identity for that record, which can originate from the patient ID, device binding ID, account identifier, medical record number, or other information that points to the patient. The record occurrence time indicates the actual time the record was created or uploaded. The source category indicates whether the record originated from the device, patient, monitoring, testing, training, medical staff, or alerting end. The data content carries specific business values. For example, the data content of a peritoneal dialysis device record may include the time of a fluid change, infusion volume, ultrafiltration volume, or alarm code; the data content of a vital signs monitoring record may include blood pressure and weight values ​​at a specific point in time.

[0024] In step 22, the system reads the patient's unique identifier, prescription start time, and prescription end time from the current prescription cycle management unit, using these as filtering boundaries. Subsequently, the system compares the patient's attribution information in a single standardized record with the patient's unique identifier, and also compares the record occurrence time with the prescription start time and prescription end time. Only when the patient's attribution information matches the patient's unique identifier, and the record occurrence time is no earlier than the prescription start time and no later than the prescription end time, does the system generate a single event for that single standardized record.

[0025] Here, a single event refers to the smallest event object that has completed patient and period assignment confirmation; that is, a valid event that belongs to the patient and falls within the current prescription period. In other words, this step not only retrieves the record but also excludes noisy records irrelevant to the current period. For example, an old device alarm record generated at the end of the previous prescription period for the same patient, even if it comes from the same device, will not be included in the current period. Similarly, a record whose time falls within the current period but whose patient assignment information does not match will not generate a single event. After this processing, the patient and time boundaries of the event are fixed, and subsequent analysis will not be biased by cross-period mixing or cross-patient misassignment.

[0026] In step 23, the system sorts the selected individual events according to their occurrence time, determines the event category based on the source category of the individual event, and uses the data content corresponding to the individual event as the specific value of the event. Then, individual events belonging to the same current prescription cycle management unit are merged to generate the current prescription cycle event set. The event category represents the result of the system's business classification of individual events, and can correspond to execution events, reporting events, monitoring events, inspection events, training events, questionnaire events, viewing and handling events, or reminder response events. The specific value of the event represents the content carrier actually used for subsequent judgment and analysis, such as execution parameters, monitoring indicators, questionnaire results, alarm information, or handling content.

[0027] After sorting the recorded events by their occurrence time, the system can organize events within the same cycle into a continuous time chain. This facilitates subsequent identification of the relationships between treatment actions and allows for observation of equipment execution, patient feedback, and medical care procedures within the same time frame. For example, if an equipment alarm occurs first, followed by a patient's abnormal report, and then a nurse reviews and processes the record, these three types of records can form a clearer sequence of events after sorting. The merged event set for the current prescription cycle is no longer a collection of isolated records, but a continuous sequence of events built around a specific patient and a specific prescription cycle.

[0028] Upon completion of this embodiment, the system organizes the original records, which were originally scattered across multiple sources including equipment, patients, monitoring, testing, and medical care, into a set of periodic events with clear attribution, time, and category. This improves the consistency of home peritoneal dialysis treatment data organization and provides a unified input basis for subsequent closed-loop treatment unit division, deviation identification, and treatment path generation. For long-term outpatient treatment scenarios, this event-based organization method helps the system continuously track changes in patient treatment execution and feedback, reducing judgment errors caused by disorganized data sources, unclear time boundaries, or confused patient attribution, and making treatment process management, remote monitoring, and medical care collaboration more coherent.

[0029] In one embodiment of the present invention, the system generates a set of closed-loop treatment units for the current prescription cycle based on the current prescription cycle event set and the prescribed actions. Here, a closed-loop treatment unit represents the smallest treatment management object established around a specific prescription action, used to organize target requirements, actual execution, post-execution feedback, and medical and nursing interventions into the same judgment structure. Unlike classification based solely on data source, closed-loop treatment units are organized around treatment actions, making them more suitable for subsequent judgments on whether the patient has completed treatment according to the prescription, whether effective feedback has been generated after treatment, and whether medical and nursing staff have conducted corresponding checks and interventions.

[0030] The current prescription cycle closed-loop treatment unit set represents a complete set of units composed of multiple individual closed-loop treatment units arranged in the order of prescription actions within the same prescription cycle. This set is not a simple summary of the original events, but rather a reorganization of the event set oriented towards the medical process. This transforms the system's subsequent processing objects from scattered records into treatment units with a structure of goals, execution, feedback, and treatment. This facilitates the identification of where a link in the treatment chain is missing and allows subsequent anomaly judgments to be based on specific treatment actions, rather than remaining at the level of fragmented data.

[0031] In step 31, the system first reads the prescribed execution actions from the current prescription cycle management unit and breaks them down into individual prescription execution actions. Here, an individual prescription execution action represents the minimum action requirement that can be independently identified, executed, and verified within the prescription cycle, such as a fluid change operation, the initiation of an automated peritoneal dialysis treatment, a post-treatment vital sign report, or a confirmation action at a specified time. By breaking down the prescribed execution actions, the system can establish corresponding relationships item by item, rather than treating the entire prescription cycle as a coarse whole.

[0032] After receiving the execution actions specified for each individual prescription, the system extracts the event category and data content corresponding to that action from the current prescription cycle event set, generating an action-corresponding event subset. This correspondence can be determined based on action type, occurrence time, device identifier, operation identifier, reported content, or preset mapping rules. For example, if a single prescription specifies the initiation of nighttime automated peritoneal dialysis, the corresponding single event could include device initiation records, treatment process parameter records, patient post-treatment symptom reports, and nurse follow-up records. By first generating action-corresponding event subsets, the system can group scattered events related to a particular treatment action into a single local area, facilitating subsequent extraction and combination.

[0033] In step 32, the system determines the target action based on the actions specified in the single prescription and extracts different categories of single events from the event subset corresponding to the action. Specifically, single events categorized as "execution" are identified as actual execution; single events categorized as "reporting, monitoring, or testing" are identified as execution feedback; and single events categorized as "viewing and handling" are identified as medical and nursing interventions. The target action represents the standard action required by the single prescription to be performed by the patient or equipment. Actual execution represents the execution status of the target action during actual treatment. Execution feedback represents the patient's report, vital sign monitoring, or test results generated after the action is completed. Medical and nursing interventions represent the viewing, confirmation, guidance, review, or intervention related to the action or its feedback results.

[0034] In other words, the system here transforms actions into a closed-loop structure. For example, if a single action represents performing a peritoneal dialysis fluid change at a specific time, the target action can represent the fluid change requirement itself; the actual execution can represent the fluid change time and execution parameters recorded by the equipment; the execution feedback can represent the drainage status, weight changes, or blood pressure reported by the patient after the fluid change; and the medical and nursing interventions can represent the nurse's review and handling opinions on this treatment record. As another example, if a single action represents timely reporting of vital signs, the target action can represent the reporting requirement itself; the actual execution can represent whether the patient submitted the data on time; the execution feedback can represent the specific vital sign data submitted; and the medical and nursing interventions can represent the subsequent review and intervention records of abnormal vital signs by medical staff.

[0035] In step 33, the system determines whether the target action, actual execution, execution feedback, and medical / nursing intervention all exist in a single closed-loop treatment unit. If all four are present, the unit is considered closed; otherwise, it is considered incomplete. Here, "closed" indicates whether the management chain corresponding to a particular treatment action has formed a complete closed-loop structure. If there are only execution records but no feedback data, or if there is feedback data but no corresponding medical / nursing review and intervention, the unit cannot be considered closed.

[0036] After generating and determining the closure status of a single closed-loop treatment unit, the system arranges the single closed-loop treatment units generated in step 32 according to the order of actions specified in the prescription. Single closed-loop treatment units belonging to the same current prescription cycle management unit are merged to generate a set of closed-loop treatment units for the current prescription cycle. Arranging them according to the prescription action order ensures that the treatment units throughout the cycle maintain the same execution order as the original prescription, facilitating subsequent observation of the evolution of the treatment chain within a given cycle. For example, the sequence of first performing device treatment, then generating vital sign feedback, followed by medical staff review, can be presented continuously in the unit set. The merged set of closed-loop treatment units retains both the local treatment loop corresponding to each action and the overall structure of multiple actions linked together throughout the entire prescription cycle.

[0037] After this embodiment is completed, the system further transforms the event set originally organized by source into a closed-loop treatment unit set organized by treatment action. This allows the system's judgment objects to be closer to the actual diagnosis and treatment management process, and also enables subsequent break identification to be based on the correspondence between the target action, actual execution, feedback results, and medical and nursing treatment. For home peritoneal dialysis scenarios, this approach helps to continuously observe equipment execution, patient self-management, and remote medical and nursing intervention within the same treatment chain, reducing the bias caused by making judgments based on a single monitoring value or a single record, and making the organization of treatment execution tracking, anomaly detection, and subsequent treatment more coherent.

[0038] In one embodiment of the present invention, the system determines a fracture type label based on the current set of closed-loop treatment units in the prescription cycle, a preset execution deviation judgment threshold, a preset feedback deviation judgment threshold, and a preset response deviation judgment threshold. Here, the fracture type label represents the system's classification result of the current instability position of a single closed-loop treatment unit, indicating whether the problem occurs in the execution, feedback, or response stages, or whether multiple stages are simultaneously abnormal. The preset execution deviation judgment threshold, preset feedback deviation judgment threshold, and preset response deviation judgment threshold represent pre-set judgment boundaries for the three types of deviations, used to transform the differences in the closed-loop treatment units into comparable and categorizable judgment results.

[0039] This step does not directly issue an alert for whether a single indicator exceeds its limit. Instead, it compares the corresponding relationships between the target actions, actual execution, execution feedback, and medical and nursing interventions within the closed-loop treatment unit layer by layer. This process allows the system not only to detect anomalies but also to identify at which link in the treatment chain the anomaly occurs, providing a clearer basis for generating subsequent repair tasks.

[0040] In step 41, the system identifies the differences between the target action and the actual execution of each individual closed-loop treatment unit in the current prescription cycle's closed-loop treatment unit set, focusing on the differences in action content, number of actions, action sequence, and action completion. These differences are then summarized to determine the execution deviation. Here, the difference in action content refers to inconsistencies between the specific treatment content required by the target action and the actual execution content. For example, the target requirement might be automated peritoneal dialysis, while the actual execution record corresponds to some manual fluid exchange procedures. The difference in the number of actions refers to the difference between the target requirement for the number of executions, execution groups, or execution items and the actual number of actions performed. The difference in the action sequence indicates inconsistencies between the prescribed order and the actual execution order of multiple actions. The difference in the action completion indicates that although an action has started, it has not been completed as required, or there have been interruptions, omissions, or premature terminations.

[0041] The system aggregates these various types of discrepancies to determine the execution deviation for each individual closed-loop treatment unit. In other words, execution deviation is not limited to whether the treatment was performed at all, but comprehensively reflects whether the treatment was performed correctly, completely, sequentially, and whether the prescription requirements were met. For example, if a treatment requires eight hours of automatic nighttime dialysis, but the equipment record shows it only ran for four hours before being interrupted, the system will still include the difference in completion status in the execution deviation, even if the execution record exists. This improves the ability to identify home treatment adherence and avoids mistaking incomplete execution for normal execution.

[0042] In step 42, the system further determines whether the execution feedback of each individual closed-loop treatment unit contains feedback items corresponding to the prescription requirements, compares the differences between the feedback content containing the included feedback items and the corresponding requirements, and then summarizes the cases of missing feedback items and differences in feedback content to determine feedback deviation. Here, missing feedback items indicate that after the target action is completed, the feedback items that should have been collected or reported did not appear. For example, the prescription requires reporting blood pressure, weight, and drainage status after treatment, but the patient only reports one of these or none at all. Differences in feedback content indicate that although feedback items exist, their content deviates from the corresponding requirements. For example, the feedback time does not meet the regulations, the feedback value is abnormal, the collected items are incomplete, or the feedback content does not meet the current cycle management requirements.

[0043] Feedback bias reflects whether the observations and feedback after treatment are complete and meet requirements, rather than simply whether a particular value is abnormal. In other words, the system at this stage focuses on whether the post-treatment information feedback is sufficient to support subsequent judgments. For example, even if a patient completes dialysis but fails to upload weight and blood pressure as required, the system will still consider this closed-loop unit to have a gap on the feedback side. Similarly, if a patient has uploaded drainage information but lacks key monitoring items required by the prescription, the system can also include this discrepancy in the feedback bias. With this processing, the system can uniformly include both post-treatment information gaps and post-treatment status abnormalities within the scope of feedback-side analysis.

[0044] In step 43, the system determines whether the medical and nursing procedures for each individual closed-loop treatment unit include corresponding viewing and handling actions, and whether the sequence of medical and nursing procedures meets the corresponding requirements. It summarizes cases of missing viewing and handling actions and discrepancies in the medical and nursing procedure sequence to identify response deviations. Here, viewing and handling actions refer to the actions taken by medical and nursing personnel to view, confirm, guide, review, intervene, or close the corresponding execution and feedback information for the closed-loop treatment unit. Whether the medical and nursing procedure sequence meets the corresponding requirements indicates whether the medical and nursing staff have completed the corresponding processing according to the established management process. For example, first viewing abnormal data, then reviewing it, and then providing processing opinions or closing the record; if the processing sequence is disordered, or key handling nodes are missing, the system can identify a deviation on the response side.

[0045] Response bias focuses on whether the medical response chain is timely, complete, and conforms to the process after patient execution and feedback. For example, if an abnormal feedback occurs in a closed-loop treatment unit, but the medical staff fails to review the record, or if the record is reviewed but no subsequent action is taken, the system can include the missing review and action in the response bias. Similarly, if in a procedure that should be reviewed before closure, the system finds that closure was performed before review, this can also be identified as a difference in the order of medical staff actions. This not only links problems arising on the patient and equipment sides with the actual response on the medical staff side, but also provides a basis for subsequently distinguishing between execution and response problems.

[0046] After determining the execution deviation, feedback deviation, and response deviation, the system compares these three types of deviations with preset execution deviation judgment thresholds, preset feedback deviation judgment thresholds, and preset response deviation judgment thresholds, respectively. If only the execution deviation exceeds the corresponding threshold, the fracture type label is determined to be an execution-type fracture; if only the feedback deviation exceeds the corresponding threshold, the fracture type label is determined to be a feedback-type fracture; if only the response deviation exceeds the corresponding threshold, the fracture type label is determined to be a response-type fracture; if at least two deviations exceed the corresponding threshold, the fracture type label is determined to be a composite fracture; if none of the three deviations exceed the corresponding threshold, the fracture type label is determined to be no fracture.

[0047] With this classification, the system outputs no longer a general conclusion of abnormality, but rather identifies at which link in the closed-loop treatment unit breaks down. Execution-related breaks tend to indicate inconsistencies between patient execution and prescription requirements; feedback-related breaks tend to indicate incomplete or non-compliant data feedback after execution; response-related breaks tend to indicate that the healthcare monitoring and treatment chain has not been closed as required; and composite breaks indicate that multiple links in the same unit are simultaneously unstable. For long-term home peritoneal dialysis management scenarios, this approach allows the system to continuously track the specific location of instability in the treatment chain and provides a more practical basis for judgment in subsequent training and repair, healthcare review, and escalation, thereby improving the consistency of judgment and the seamlessness of treatment in remote treatment management.

[0048] In one embodiment of the present invention, the system generates a repair task package based on the correspondence between fracture type labels and preset treatment paths. The repair task package represents a treatment carrier generated for the current fracture state of a single closed-loop treatment unit, used to organize the subsequent repair actions, responsible parties, processing order, and completion requirements into executable task content. The preset treatment path correspondence represents a mapping rule pre-established by the system between fracture types and treatment methods, enabling different fracture types to enter different repair paths, rather than uniformly using the same reminder or intervention method. The repair task package may include a training repair task package, a medical review task package, an upgrade transfer task package, or a composite treatment task package.

[0049] In this process, the system no longer stops at identifying the location of the abnormality or break, but further transforms the breakage determination into subsequent actionable tasks. In other words, the system organizes repair actions around the link where the breakage occurs. This allows patient execution deviations, feedback deviations, and medical staff response deviations to be processed in different links, and also reduces the mixing and duplication of various problems in subsequent treatments.

[0050] In step 51, the system reads the fracture type label corresponding to each individual closed-loop treatment unit from the fracture type label set, and determines the corresponding training and repair path for execution-type fractures, the medical staff review path for feedback-type fractures, the escalation and transfer path for response-type fractures, and the composite treatment path for complex fractures according to the preset treatment path correspondence. The training and repair path here refers to a treatment path mainly focused on patient operation correction, training reinforcement, or reconfirmation of execution requirements, applicable to situations where there is a difference between the target action and the actual execution. The medical staff review path refers to a treatment path mainly focused on the responsible medical staff team reviewing, verifying, analyzing, and judging the feedback content again, applicable to situations where feedback is missing after execution or the feedback content does not meet the requirements. The escalation and transfer path refers to a treatment path that elevates responsibility, reassigns, or supervises the transfer of missing, delayed, or sequential issues on the medical staff treatment side, applicable to situations where the response chain is not closed as required. The composite treatment path is used in scenarios where two or more types of fractures exist simultaneously in the same closed-loop treatment unit.

[0051] With this setup, the system can directly convert fracture tags into subsequent business actions. For example, if a closed-loop treatment unit is identified as having an execution-related fracture, the system will not prioritize generating a simple medical care upgrade task, but will first enter the training and repair path; if the fracture manifests as incomplete feedback items or feedback content that does not meet requirements, the system will prioritize review by the responsible medical care team, rather than directly requiring the patient to repeat the procedure. This ensures that the repair actions are more closely aligned with the source of the fracture and makes the subsequent processing sequence clearer.

[0052] In step 52, for a single closed-loop treatment unit with a treatment path that is a training and repair path, the system generates a training and repair task package based on the differences between the target action and the actual execution. This training and repair task package may include prompts for the differing action, relearning content, confirmation requirements, prompts for supplementary execution, time-limited completion requirements, or resubmission requirements. Its purpose is to allow patients or caregivers to correct the identified execution deviations. For example, if the system identifies that a patient did not complete a fluid change operation in the prescribed order, the training and repair task package may include prompts for the corresponding operation steps and a reconfirmation requirement.

[0053] For a single closed-loop treatment unit with a treatment path that follows a medical staff review path, the system generates a medical staff review task package based on the differences between the execution feedback and the prescription requirements, and the responsible medical staff group. This task package is primarily for the responsible medical staff group and may include feedback items pending review, missing feedback item prompts, abnormal feedback item prompts, relevant periodic data entry points, and requirements for completing review opinions. For example, if a patient has completed treatment but failed to report their weight and blood pressure as required, or if the reported data is inconsistent with the requirements for this period, the system can compile these discrepancies into a medical staff review task package and push it to the corresponding responsible medical staff group. The medical staff can then further determine whether supplementary data collection, reporting, or intervention is necessary.

[0054] For a single closed-loop treatment unit with an escalation workflow, the system generates an escalation workflow task package based on missing items, non-conforming sequences, and the responsible medical team in the medical and nursing procedures. The escalation workflow task package is primarily used to address situations where the medical and nursing response chain is not completed as required. It may include incomplete review items, incomplete treatment items, sequence anomalies, information on escalated responsibility levels, reassignment information, or expedited processing requests. For example, if an anomaly feedback has been generated but no review record is found within the specified time, or if the order of review before closure is reversed, the system can generate an escalation workflow task package around these issues and send it to a higher responsibility level or a reassigned management entity. This not only fills the gaps in the medical and nursing response chain but also prevents problems from remaining unresolved at the original responsibility node for an extended period.

[0055] In step 53, for a single closed-loop treatment unit with a composite treatment path, the system extracts the differences between the target action and the actual execution, the differences between the execution feedback and the prescription requirement feedback, as well as missing items and non-conforming sequences in the medical and nursing procedures. These are then merged and encapsulated according to the order of affiliation within the same single closed-loop treatment unit to generate a composite treatment task package. This affiliation order maintains the correspondence between various issues within the same closed-loop treatment unit and their corresponding relationships in the original treatment chain, ensuring that execution issues, feedback issues, and response issues are organized uniformly around the same unit rather than being scattered into unrelated tasks.

[0056] Composite handling task packages are suitable for situations where multiple aspects of a treatment unit simultaneously become unstable. For example, a patient's dialysis procedure may not have been performed completely as required, post-treatment feedback may be incomplete, and medical staff may lack timely review of records. In such cases, the system does not break the problem into unrelated, fragmented tasks, but rather packages multiple discrepancies into a single composite handling task package. This allows subsequent personnel to see the complete chain of problems within the same treatment unit at once, while maintaining consistency between the handling process and the original closed-loop structure.

[0057] After generating training and repair task packages, medical review task packages, upgrade transfer task packages, or combined treatment task packages for each individual closed-loop treatment unit, the system merges these task packages to generate a repair task package set. The repair task package set represents the total set of tasks corresponding to all units to be repaired within the current prescription cycle, preserving both the independence of each unit and the overall structure of multi-task parallel management throughout the cycle. The system can then use this set for task assignment, status tracking, result collection, and closed-loop confirmation.

[0058] Upon completion of this embodiment, the system can further transform fracture type labels into a set of repair task packages with clearly defined paths, responsibilities, and contents. This allows patients to enter their respective processing loops for corrective actions, feedback review, and response escalation, while also enabling the continuous tracking of multiple instability issues within the same prescription cycle under a unified structure. For long-term home peritoneal dialysis management scenarios, this task-based organization method helps improve the consistency of treatment and the degree of accountability in remote management, enabling the system not only to identify problems but also to continuously promote repair around the problematic stage.

[0059] In one embodiment of the present invention, the system determines the closed-loop treatment unit repair result, cycle convergence, cycle instability, and current prescription cycle state based on the execution result of the repair task package and the current set of closed-loop treatment units in the prescription cycle. Here, the execution result of the repair task package represents the record of results generated after the execution of training repair, medical review, escalation transfer, or combined treatment tasks triggered around a certain closed-loop treatment unit. The closed-loop treatment unit repair result indicates whether the unit has recovered to a state that meets the current prescription cycle management requirements after appropriate treatment. The cycle convergence indicates the degree to which all closed-loop treatment units in the current prescription cycle converge towards the repaired state; the cycle instability indicates the number of units in the current cycle that have not yet completed repair or whose fractured state has not yet been eliminated; and the current prescription cycle state represents the system's phased judgment result on the overall operation of the cycle.

[0060] This part doesn't simply record whether a task was clicked or viewed; it further determines whether the task execution truly facilitated the restoration of the treatment chain. In other words, the system focuses not only on whether intervention was performed, but also on whether a verifiable closed-loop structure is re-established between the target action, execution feedback, and medical intervention after intervention. This avoids misjudging formal task completion as treatment recovery and ensures that the cyclical status is based on actual repair results.

[0061] In step 61, the system reads the repair task package and its execution result corresponding to each individual closed-loop treatment unit, and verifies whether the execution result of the repair task package simultaneously includes a treatment action completion record, a patient re-execution completion record, an execution feedback update record, and a medical staff signature closure record. Here, the treatment action completion record indicates that the repair action issued by the system for that unit has been actually executed, such as a training task completed, a review task submitted, or an escalation process processed. The patient re-execution completion record indicates that the patient or caregiver has re-completed the corresponding operation according to the repair requirements. The execution feedback update record indicates that the vital signs, reports, tests, or related feedback content surrounding that unit have been updated to the latest status. The medical staff signature closure record indicates that the responsible medical staff has confirmed the treatment result of that unit and completed the closure.

[0062] When all four types of records are present, the system determines the closed-loop confirmation result as complete; when at least one type of record is missing, the system determines the closed-loop confirmation result as incomplete. The closed-loop confirmation result here represents the system's judgment on whether the repair chain has complete evidence. For example, if the patient completes the re-execution but no new feedback update record is generated, the system will not directly determine that the unit has completed closed-loop confirmation. Similarly, if the feedback has been completed but the healthcare provider has not yet signed off on the closure, the system can also determine that the unit is still in an incomplete confirmation state.

[0063] In step 62, the system determines the repair result of each individual closed-loop treatment unit based on the closed-loop confirmation result. When the closed-loop confirmation result is "confirmed as complete," the system further verifies the consistency between the actual execution and the target action, whether the execution feedback has been updated to meet the requirements of the current prescription cycle management unit, and whether the medical treatment is in the "signed-off" state. Only when all three verification results are true does the system determine that the closed-loop treatment unit repair result is "repaired"; if any one of them is false, it is determined to be "not repaired."

[0064] The consistency between actual execution and target action here indicates that, after repair, the execution status of the patient or equipment has re-corresponded to the original prescription requirements. The execution feedback meeting the requirements of the current prescription cycle management unit indicates that previously missing or abnormal feedback items have been supplemented or updated to an acceptable range. The medical and nursing procedures being in a signed-off and closed state indicates that the medical and nursing staff are no longer merely observing or processing, but have completed confirmation and closure. In other words, for a unit to be considered repaired, it requires not only traces of task execution but also genuine correction of the execution content, genuine updating of feedback content, and a genuine closure of the medical and nursing chain. For example, if a dialysis session triggers training repair due to an incorrect execution sequence, and the patient later completes the procedure again, but the new feedback data is still incomplete, then the unit cannot be considered repaired. This improves the accuracy of repair determination and reduces misjudgments based solely on superficial task completion.

[0065] In step 63, the system calculates the number of repaired individual closed-loop treatment units and the total number of closed-loop treatment units in the current prescription cycle's closed-loop treatment unit set. The ratio of the number of repaired individual closed-loop treatment units to the total number of closed-loop treatment units is determined as the cycle convergence. The cycle convergence reflects the proportion of treatment units that have recovered to a satisfactory state throughout the entire prescription cycle. A higher cycle convergence indicates better closed-loop recovery in the current cycle and higher consistency between prescription execution, feedback collection, and medical care intervention.

[0066] Simultaneously, the system counts the number of individual closed-loop treatment units whose repair results are not repaired and whose corresponding original fracture type labels have not been eliminated, and uses this to determine the cycle instability. The cycle instability here represents the scale of units that remain in a fractured state and have not been effectively repaired at the end of the current prescription cycle. A higher value indicates more persistent problems in the treatment chain during the current cycle, requiring stronger subsequent management.

[0067] After obtaining the cycle convergence and cycle instability, the system determines the current prescription cycle status. When the cycle convergence reaches the point where all closed-loop treatment units have been repaired and the cycle instability is zero, the current prescription cycle is determined to be a stable cycle. When the cycle convergence reaches a preset observation threshold and the cycle instability does not exceed a preset observation upper limit, it is determined to be an observation cycle. Otherwise, it is determined to be an unstable cycle. Here, a stable cycle indicates that all closed-loop treatment units within the current cycle have been repaired, and the entire treatment cycle is in a relatively stable state. An observation cycle indicates that although most repairs have been completed, some units still require continued attention. An unstable cycle indicates that there are still many unrepaired or unresolved fractures in the current cycle, and the conditions for a stable transition to the next management stage are not yet met.

[0068] After this embodiment is completed, the system can further convert the results of individual task execution into unit-level repair conclusions, and then summarize multiple unit-level conclusions into cycle-level status results. This allows prescription cycle management to move beyond the superficial level of whether tasks are issued and processed, and enables the system to evaluate the quality of the current cycle based on the actual treatment and recovery situation. For long-term outpatient treatment scenarios such as home peritoneal dialysis, this approach helps to continuously reflect the actual effects of patient implementation of corrections, feedback completion, and medical care intervention closure, making cycle management results closer to the continuous tracking needs in the clinical remote management process, and providing a more reliable basis for adjusting management strategies in the next cycle.

[0069] In one embodiment of the present invention, the system generates a next-cycle inheritance strategy, a next-cycle management unit, and a patient lifecycle state chain based on the current prescription cycle status, the amount of cycle instability, the set of break type labels, and the set of closed-loop treatment unit repair results. The next-cycle inheritance strategy represents the management continuation rules determined by the system for the next prescription cycle after the current cycle ends, based on the results of this cycle. This strategy determines whether the next cycle maintains the original management intensity in terms of responsibility allocation, execution requirements, and feedback requirements, or enters a state of enhanced observation or intervention. The patient lifecycle state chain represents a chronological sequence of management units for the same patient across multiple consecutive prescription cycles, reflecting the continuous management evolution of the patient during long-term home peritoneal dialysis treatment.

[0070] In step 71, the system determines the inheritance strategy for the next cycle based on the current prescription cycle status, cycle instability level, set of fracture type labels, and set of closed-loop treatment unit repair results. When the current prescription cycle status is a stable cycle, the cycle instability level is zero, there are no unresolved complex fractures or response fractures in the fracture type label set, and all repair results in the closed-loop treatment unit set are complete, the system determines the next cycle inheritance strategy as a stable inheritance strategy. Here, a stable inheritance strategy indicates that the prescription execution, feedback collection, and healthcare response for the current cycle have formed a relatively complete closed loop, and the next cycle can continue to use the existing configuration while maintaining the current responsibility relationship and management framework, without needing to increase the intervention level.

[0071] In other words, when determining a stable inheritance strategy, the system not only considers whether the cycle state is stable, but also performs further verification based on the instability amount, fracture label, and repair results. Only when there are no residual complex or response issues in the current cycle, and all closed-loop treatment units have been repaired, will the system consider the cycle as a state where it can smoothly transition to the next cycle.

[0072] In step 72, the system determines whether to enter the instability inheritance strategy. When the current prescription cycle is an unstable cycle, the cycle instability exceeds the preset observation limit, there are unresolved complex or response-type fractures in the fracture type label set, or there are unrepaired fractures in the closed-loop treatment unit repair results set, the system determines the next cycle's inheritance strategy to be the instability inheritance strategy. Here, the instability inheritance strategy means that the next cycle cannot simply continue the current management intensity, but needs to further tighten the responsibility configuration, reminder frequency, review intensity, or key action focus scope to accommodate the risks and fracture issues that have not yet been eliminated in the current cycle.

[0073] For example, if some repairs have been completed in the current cycle, but the healthcare response chain remains incomplete, or some closed-loop treatment units remain unrepaired, the system can designate the next cycle as an instability inheritance strategy. With this approach, the next cycle can move away from the previous lenient management method and enter a more intensive continuous tracking state. The purpose of instability inheritance is not simply to label problems, but to carry over the problems left over from the current cycle to the starting point of the next cycle's management, preventing problems from being interrupted or lost during cycle switching.

[0074] When the current prescription cycle does not meet the criteria for either a stable or unstable inheritance strategy, the system determines the next cycle's inheritance strategy as an observational inheritance strategy. An observational inheritance strategy indicates that the overall operation of the current cycle is between stable and unstable; although most closed-loop treatment units have been repaired, some issues still require continued attention in the next cycle. In this situation, the system can maintain the original cycle framework while appropriately retaining and continuing some actions, feedback items, or points of focus for healthcare professionals, thus ensuring continuous observation characteristics in the next cycle.

[0075] In step 73, the system determines the immediate time point following the prescription's effective end time in the current prescription cycle management unit as the start time of the next cycle, and determines the end time of the next cycle based on the preset cycle length corresponding to the current valid dialysis prescription. Here, the immediate time point refers to the next management time point that connects to the end time of the current cycle, ensuring temporal continuity between cycles. The preset cycle length represents the management length pre-set for the current valid dialysis prescription, which can be set according to the dialysis plan, hospital rules, or follow-up requirements.

[0076] After determining the start and end times of the next cycle, the system, based on the next cycle inheritance strategy and the current prescription cycle management unit, determines the next responsible medical staff group, the next prescription's prescribed actions, and the next prescription's required feedback items, and generates the next prescription cycle management unit. This determination can be a direct continuation or an adjustment based on the existing system. For example, under a stable inheritance strategy, the next responsible medical staff group and feedback requirements can remain unchanged; under an observational inheritance strategy, the system can retain the original responsible group while continuously including some key feedback items in the observation; under an unstable inheritance strategy, the system can strengthen the confirmation requirements for responsibility levels, review density, or key actions. For instance, if post-treatment feedback is repeatedly missing in the current cycle, the system can continue to focus on that feedback item in the next cycle and increase the corresponding confirmation frequency.

[0077] When the unique patient identifiers in the current prescription cycle management unit and the next prescription cycle management unit are identical and their time boundaries are consecutive, the system links the current and next prescription cycle management units in chronological order to generate a patient's entire lifecycle state chain. This linking is not simply archiving; rather, it connects multiple cycle management units based on the same patient, consecutive time boundaries, and sequential inheritance relationships. This makes each cycle both an independent management unit and a continuous node in the entire long-term treatment process. As cycles progress, the system gradually forms a state chain covering the entire process of home dialysis for patients.

[0078] After this embodiment is completed, the system can transform the status result of a single prescription cycle into the management starting point for the next cycle, creating a continuous succession relationship between cycles. This allows stable cycles to maintain their existing good management status, while observation and unstable cycles can carry over any unresolved issues to the next cycle for continuous tracking. For long-term home peritoneal dialysis management scenarios, this approach, based on a cycle status generation and inheritance strategy and linked together to form a full life-cycle status chain, helps maintain the continuity of patient treatment records and the continuity of management strategies. It enables the system to continuously conduct remote management and collaborative processing around long-term changes in patient treatment, rather than fragmenting each cycle into unrelated independent segments.

[0079] In one embodiment of the present invention, an intelligent method for full-life-cycle management of peritoneal dialysis for kidney disease is also provided, comprising the following steps: Step 81: Obtain patient identity information, current valid dialysis prescription, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; Step 82: Obtain peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and generate the current prescription cycle event set based on the current prescription cycle management unit; Step 83: Generate a set of closed-loop treatment units for the current prescription cycle based on the event set of the current prescription cycle and the actions to be performed according to the prescription. Step 84: Determine the breakage type label based on the current prescription cycle closed-loop treatment unit set, the preset execution deviation judgment threshold, the preset feedback deviation judgment threshold, and the preset response deviation judgment threshold; Step 85: Generate a repair task package based on the correspondence between the fracture type label and the preset treatment path. The repair task package includes a training repair task package, a medical review task package, an upgrade transfer task package, or a composite treatment task package. Step 86: Based on the execution results of the repair task package and the current prescription cycle closed-loop treatment unit set, determine the closed-loop treatment unit repair results, cycle convergence, cycle instability, and current prescription cycle status. Step 87: Based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results, generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle status chain.

[0080] It should be noted that the range and threshold size are set for ease of comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data, as long as it does not affect the ratio between the parameter and the quantized value.

[0081] The embodiments of the present invention have been described above, but the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms based on the guidance of the present embodiments, all of which are within the protection scope of the present embodiments.

Claims

1. An intelligent peritoneal dialysis full life cycle management system for kidney disease, characterized in that, include: The patient registration module is used to obtain patient identity information, current valid dialysis prescriptions, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; The event aggregation module is used to acquire peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and to generate the current prescription cycle event set based on the current prescription cycle management unit; The closed-loop construction module is used to generate a set of closed-loop treatment units for the current prescription cycle based on the event set and prescription regulations of the current prescription cycle. The fracture determination module is used to determine the fracture type label based on the current prescription cycle closed-loop treatment unit set, preset execution deviation determination threshold, preset feedback deviation determination threshold, and preset response deviation determination threshold. The task generation module is used to generate repair task packages based on the correspondence between fracture type labels and preset treatment paths. The repair task packages include training repair task packages, medical review task packages, upgrade transfer task packages, or composite treatment task packages. The state convergence module is used to determine the closed-loop treatment unit repair result, cycle convergence, cycle instability and current prescription cycle state based on the execution result of the repair task package and the current prescription cycle closed-loop treatment unit set; The cycle inheritance module is used to generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle state chain based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results.

2. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, The system retrieves patient identity information, current valid dialysis prescriptions, prescription start time, prescription end time, responsible medical team, prescription execution actions, and prescription requirement feedback items to generate a unique patient identifier and a current prescription cycle management unit, including: Step 11: Perform a completeness check on the patient's identity information, the current valid dialysis prescription, the prescription's effective start time, the prescription's effective end time, the responsible medical team, the prescribed actions to be performed, and the prescription's feedback requirements. Determine whether the patient's identity information, the current valid dialysis prescription, the prescription's effective start time, the prescription's effective end time, the responsible medical team, the prescribed actions to be performed, and the prescription's feedback requirements all exist and are not empty. Step 12: Perform a time sequence check on the prescription effective start time and prescription effective end time, and determine whether the prescription effective end time is later than the prescription effective start time; perform a correspondence check on the responsible medical care group, the prescription prescribed execution actions and the prescription requirement feedback items, and determine whether the responsible medical care group corresponds to the current valid dialysis prescription, and whether the prescription prescribed execution actions and prescription requirement feedback items are all derived from the current valid dialysis prescription; Step 13: Standardize the patient identity information that has passed integrity verification, time sequence verification, and correspondence verification, and generate a unique code based on the standardized patient identity information. Use the unique code as the patient's unique identifier. Bind the patient's unique identifier, the current valid dialysis prescription, the prescription's effective start time, the prescription's effective end time, the responsible medical team, the prescription's prescribed execution actions, and the prescription's required feedback items to generate the current prescription cycle management unit.

3. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, Acquire peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical staff observation and treatment records, and reminder sending and response records. Based on the current prescription cycle management unit, generate the current prescription cycle event set, including: Step 21: Collect peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records; extract patient attribution information, record occurrence time, source category, and data content from each collected record, and write the patient attribution information, record occurrence time, source category, and data content into a single standardized record; Step 22: Read the patient's unique identifier, prescription start time, and prescription end time from the current prescription cycle management unit; compare the patient's attribution information in a single standardized record with the patient's unique identifier, compare the record occurrence time with the prescription start time and prescription end time, and generate a single event for single standardized records where the patient's attribution information matches the patient's unique identifier and the record occurrence time is no earlier than the prescription start time and no later than the prescription end time; Step 23: Sort the individual events according to their recorded occurrence time, determine the event category based on the source category of the individual event, and use the data content corresponding to the individual event as the specific value of the event. Merge the individual events belonging to the same current prescription cycle management unit to generate the current prescription cycle event set.

4. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, Based on the current prescription cycle event set and the prescribed actions, a set of closed-loop treatment units for the current prescription cycle is generated, including: Step 31: Read the prescription execution actions from the current prescription cycle management unit and break them down into individual prescription execution actions; based on each individual prescription execution action, extract the event category and data content corresponding to each individual prescription execution action from the current prescription cycle event set, and generate an action-corresponding event subset; Step 32: Determine the target action according to the action specified in the single prescription, extract the single event of the event category as execution from the event subset corresponding to the action as the actual execution, extract the single event of the event category as reporting, monitoring or inspection as the execution feedback, extract the single event of the event category as viewing treatment as the medical and nursing treatment, and generate a single closed-loop treatment unit based on the target action, actual execution, execution feedback and medical and nursing treatment. Step 33: Determine whether the target action, actual execution, execution feedback, and medical care treatment in a single closed-loop treatment unit all exist. If all exist, the closed state is determined to be closed; if any are missing, the closed state is determined to be unclosed. Arrange the single closed-loop treatment units generated in Step 32 according to the order of the execution actions specified in the prescription. Merge the single closed-loop treatment units belonging to the same current prescription cycle management unit to generate a set of closed-loop treatment units for the current prescription cycle.

5. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, The breakage type label is determined based on the current prescription cycle closed-loop treatment unit set, preset execution deviation judgment threshold, preset feedback deviation judgment threshold, and preset response deviation judgment threshold, including: Step 41: For each individual closed-loop treatment unit in the current prescription cycle closed-loop treatment unit set, determine the differences between the target action and the actual execution in terms of action content, number of actions, action sequence, and action completion status, and summarize the differences in action content, number of actions, action sequence, and action completion status to determine the execution deviation; Step 42: For each individual closed-loop treatment unit in the current prescription cycle closed-loop treatment unit set, determine whether the execution feedback contains the feedback item corresponding to the prescription requirement feedback item, and compare the difference between the feedback content that already contains the feedback item and the corresponding requirement; summarize the feedback item missing situation and the feedback content difference situation to determine the feedback deviation. Step 43: For each individual closed-loop treatment unit in the current prescription cycle closed-loop treatment unit set, determine whether the medical and nursing procedures include the corresponding viewing and treatment actions, and determine whether the medical and nursing procedure sequence meets the corresponding requirements; summarize the cases of missing viewing and treatment actions and the differences in the medical and nursing procedure sequence to determine the response deviation; compare the execution deviation, feedback deviation, and response deviation with the preset execution deviation judgment threshold, preset feedback deviation judgment threshold, and preset response deviation judgment threshold, respectively; when only the execution deviation exceeds the corresponding threshold, determine the fracture type label as execution-type fracture; when only the feedback deviation exceeds the corresponding threshold, determine the fracture type label as feedback-type fracture; when only the response deviation exceeds the corresponding threshold, determine the fracture type label as response-type fracture; when at least two deviations exceed the corresponding threshold, determine the fracture type label as composite fracture; when none of the three deviations exceed the corresponding threshold, determine the fracture type label as no fracture.

6. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, Repair task packages are generated based on the correspondence between fracture type labels and preset treatment paths. These repair task packages include training repair task packages, medical review task packages, upgrade transfer task packages, or composite treatment task packages, including: Step 51: Read the fracture type label corresponding to each individual closed-loop treatment unit from the fracture type label set, and determine the training and repair path corresponding to the execution fracture, the medical and nursing review path corresponding to the feedback fracture, the upgrade and transfer path corresponding to the response fracture, and the composite treatment path corresponding to the composite fracture according to the preset treatment path correspondence. Step 52: For a single closed-loop treatment unit with a treatment path of training and repair, generate a training and repair task package based on the differences between the target action and the actual execution; for a single closed-loop treatment unit with a treatment path of medical and nursing review, generate a medical and nursing review task package based on the differences between the execution feedback and the prescription requirement feedback items and the responsible medical and nursing group; for a single closed-loop treatment unit with a treatment path of escalation and transfer, generate an escalation and transfer task package based on the missing items, non-conforming sequence items in the medical and nursing treatment and the responsible medical and nursing group. Step 53: For a single closed-loop treatment unit with a composite treatment path, extract the differences between the target action and the actual execution, the differences between the execution feedback and the prescription requirement feedback, as well as the missing items and non-sequential items in the medical and nursing treatment, and merge and package them into a composite treatment task package according to the order of the same single closed-loop treatment unit; merge the training repair task package, medical and nursing review task package, upgrade transfer task package or composite treatment task package corresponding to each single closed-loop treatment unit to generate a repair task package set.

7. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, Based on the execution results of the repair task package and the current prescription cycle closed-loop treatment unit set, determine the closed-loop treatment unit repair results, cycle convergence, cycle instability, and current prescription cycle state, including: Step 61: Read the repair task package and the execution result of the repair task package corresponding to each individual closed-loop treatment unit, and check whether the execution result of the repair task package simultaneously includes the treatment action completion record, the patient re-execution completion record, the execution feedback update record, and the medical staff signing and closing record; if all four types of records exist, the closed-loop confirmation result is determined to be confirmed as completed; if at least one type of record is missing, the closed-loop confirmation result is determined to be confirmed as incomplete. Step 62: Determine the closed-loop treatment unit repair result corresponding to each individual closed-loop treatment unit based on the closed-loop confirmation result; when the closed-loop confirmation result is confirmed as completed, further verify the consistency between the actual execution and the target action, whether the execution feedback has been updated to meet the requirements of the current prescription cycle management unit, and whether the medical and nursing treatment is in the signed-off and closed state; if all three verification results are met, the closed-loop treatment unit repair result is determined to be repaired; otherwise, it is determined to be unrepaired. Step 63: Calculate the number of repaired individual closed-loop treatment units and the total number of closed-loop treatment units in the current prescription cycle's closed-loop treatment unit set, and determine the cycle convergence as the ratio of the number of repaired individual closed-loop treatment units to the total number of closed-loop treatment units; calculate the number of unrepaired individual closed-loop treatment units whose corresponding original fracture type labels have not been eliminated, and determine this number as the cycle instability; when the cycle convergence reaches the point where all closed-loop treatment units have been repaired and the cycle instability is zero, determine the current prescription cycle as a stable cycle; when the cycle convergence reaches a preset observation threshold and the cycle instability does not exceed a preset observation upper limit, determine it as an observation cycle; otherwise, determine it as an unstable cycle.

8. The intelligent peritoneal dialysis full life cycle management system for kidney disease according to claim 1, characterized in that, Based on the current prescription cycle status, cycle instability amount, set of break type labels, and set of closed-loop treatment unit repair results, a next cycle inheritance strategy, a next prescription cycle management unit, and a patient lifecycle status chain are generated, including: Step 71: Determine the next cycle inheritance strategy based on the current prescription cycle status, cycle instability amount, fracture type label set, and closed-loop treatment unit repair results set; if the current prescription cycle status is a stable cycle, the cycle instability amount is zero, there are no unresolved complex fractures or responsive fractures in the fracture type label set, and all closed-loop treatment unit repair results set are repaired, then the next cycle inheritance strategy is determined to be a stable inheritance strategy. Step 72: If the current prescription cycle is an unstable cycle, the cycle instability exceeds the preset observation limit, there are unresolved complex fractures or response fractures in the fracture type label set, or there are unrepaired fractures in the closed-loop treatment unit repair result set, the next cycle inheritance strategy is determined to be an unstable inheritance strategy; if the current prescription cycle does not meet the stable inheritance strategy determination condition and does not meet the unstable inheritance strategy determination condition, the next cycle inheritance strategy is determined to be an observation inheritance strategy. Step 73: Determine the immediate time point following the prescription effective end time of the current prescription cycle management unit as the start time of the next cycle, and determine the end time of the next cycle based on the preset cycle length corresponding to the current valid dialysis prescription; Based on the next cycle inheritance strategy and the current prescription cycle management unit, determine the next responsible medical team, the next prescription's prescribed execution actions, and the next prescription's required feedback items, and generate the next prescription cycle management unit; When the patient's unique identifier is consistent in the current prescription cycle management unit and the next prescription cycle management unit and the time boundaries are connected end to end, connect the current prescription cycle management unit and the next prescription cycle management unit in chronological order to generate a patient's full life cycle status chain.

9. An intelligent method for the whole life cycle management of peritoneal dialysis for kidney disease, characterized in that, The intelligent peritoneal dialysis full life cycle management system for kidney disease as described in any one of claims 1-8 includes the following steps: Step 81: Obtain patient identity information, current valid dialysis prescription, prescription effective start time, prescription effective end time, responsible medical team, prescription execution actions and prescription requirement feedback items, and generate a unique patient identifier and current prescription cycle management unit; Step 82: Obtain peritoneal dialysis equipment execution records, patient manual reporting records, vital sign monitoring records, laboratory test results, patient training and questionnaire records, medical and nursing observation and treatment records, and reminder sending and response records, and generate the current prescription cycle event set based on the current prescription cycle management unit; Step 83: Generate a set of closed-loop treatment units for the current prescription cycle based on the event set of the current prescription cycle and the actions to be performed according to the prescription. Step 84: Determine the breakage type label based on the current prescription cycle closed-loop treatment unit set, the preset execution deviation judgment threshold, the preset feedback deviation judgment threshold, and the preset response deviation judgment threshold; Step 85: Generate a repair task package based on the correspondence between the fracture type label and the preset treatment path. The repair task package includes a training repair task package, a medical review task package, an upgrade transfer task package, or a composite treatment task package. Step 86: Based on the execution results of the repair task package and the current prescription cycle closed-loop treatment unit set, determine the closed-loop treatment unit repair results, cycle convergence, cycle instability, and current prescription cycle status. Step 87: Based on the current prescription cycle status, cycle instability amount, set of fracture type labels, and set of closed-loop treatment unit repair results, generate the next cycle inheritance strategy, the next prescription cycle management unit, and the patient's full life cycle status chain.

Images