Method and device for cooperative linkage control of multiple pet feeders and storage medium

Abstract

The present application relates to the field of pet medical care intelligence, and particularly relates to a multi-pet feeder cooperative linkage control method and device and a storage medium, the method comprising taking a sick pet as the core, realizing unified hosting of feeding data and global management of equipment state through a global control platform; after sensing the position change of the sick pet and passing multi-layer legality verification, automatically completing original feeder task unbinding, target feeder matching and rearrangement based on the original medical constraint queue, realizing dynamic migration of the feeding task with the sick pet; all feeding data carries the sick pet identity, and is continuously collected and synchronized to the electronic medical record according to the identity. The present application solves the specific problems that the feeding task cannot be dynamically migrated, the nursing data is broken, and the constraint rules cannot be continued in the pet hospital inpatient turnover scene, can greatly reduce the feeding error rate in the transfer cage scene, guarantee the continuity of the electronic medical record, and improve the automation and standardization level of inpatient feeding and nursing.

Description

Technical Field

[0001] This invention belongs to the field of intelligent pet medical care, specifically involving a method, device, and storage medium for the coordinated control of multiple pet feeders. Background Technology

[0002] With the standardization of the companion animal healthcare industry and the continuous upgrading of pet medical needs, the standardization and automation of inpatient care in pet hospitals have become one of the core indicators for measuring hospital service capabilities. Regular and quantitative feeding of hospitalized pets is a core aspect of basic care, directly affecting their nutritional intake, medication adherence, and postoperative recovery. It is also crucial nursing data that must be fully recorded in the inpatient electronic medical record.

[0003] Hospitalized pets frequently change locations across cages and even wards due to factors such as adjustments in disease severity, changes in ward isolation, return from external examinations, and cage disinfection rotations. Consequently, the corresponding feeder devices change. Current technology uses a static task-feeder binding scheduling model, which cannot support dynamic migration of feeding tasks with sick pets. This easily leads to errors such as missed feeding tasks during transition periods and duplicate feeding on old and new cage devices. Furthermore, task execution progress, historical constraint rules, and feeding data cannot be continuously collected according to the pet's identity, causing gaps in feeding and care data in electronic medical records. This also prevents the continuation of original medical constraint priorities and time window rules during rescheduling. Summary of the Invention

[0004] The purpose of this invention is to provide a method, device, and storage medium for the coordinated control of multiple pet feeders, in order to solve the problems mentioned in the background art.

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0006] A method for coordinated control of multiple pet feeders, including the following steps:

[0007] When a sick pet is admitted to the hospital, the global management platform generates a globally unique identification identifier for the sick pet, establishes a feeding prescription and medical restraint rule file bound to this identifier, and connects to the hospital's inpatient and electronic medical record systems to achieve unified data management;

[0008] The global management platform pre-stores a one-to-one mapping relationship between cage positions and feeders, continuously collects the feeder's operating data, including the feeder's online status, task queue, and food storage, and updates the global device status pool in real time.

[0009] Upon receiving a pet location change event, the platform sequentially completes the verification of the pet's identity in the hospital, the availability of the target cage, and the adaptation to isolation in the ward. Once all verifications are passed, the task migration process is officially initiated.

[0010] The platform issues an unbinding command to the original feeder, clearing all unexecuted tasks for the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution.

[0011] Each feeder reports execution data carrying the pet's identification identifier. The platform collects feeding data for the entire hospitalization period according to the pet's identification and updates it synchronously to the corresponding electronic medical record.

[0012] Furthermore, the triggering channels for the pet's location change event include:

[0013] Manual scanning trigger: When nursing staff perform cage transfer operations, they use an in-hospital mobile terminal to scan the QR code on the pet's identification wristband and the QR code of the target cage, and submit a cage transfer application to trigger a location change event.

[0014] Inpatient system medical order push trigger: When clinicians issue medical orders such as transfer to another ward, transfer to another department, or outpatient examination, the inpatient management system automatically pushes the location change event to the global management platform;

[0015] Return from an outpatient check-up trigger: When a sick pet returns to the ward after an outpatient check-up, the caregiver scans the pet's identification wristband and the QR code for returning to its cage, triggering a location return event.

[0016] Furthermore, the validity check also includes a time validity check: if the event carries a specified effective time, the validity of the effective time is checked, and retrospective location changes are prohibited; all checks must pass for the event to be considered valid, and if any check fails, the change event is rejected and a reason for failure is returned.

[0017] Furthermore, upon receiving the unbinding command, the original feeder simultaneously performs the following operations:

[0018] Remove all unexecuted feeding tasks for the corresponding sick pet from the local task queue and clear the relevant task commands from the local cache;

[0019] Lock the feeding permissions for the sick pet and prohibit any feeding actions from being initiated;

[0020] The system sends a successful unbinding response to the global management platform and reports the execution progress of all tasks for the sick pet in the current queue.

[0021] If a feeding task is in progress when the device is unbound, the original feeder will immediately pause the feeding action, record the weight of the food already fed, and report the task interruption status and the amount of food fed to the global management platform.

[0022] Furthermore, when matching a target feeder, the global management platform retrieves real-time data from the global device status pool to perform a secondary availability check on the target feeder, confirming that its online status is normal, it is in an available state, and its food reserves meet the feeding prescription requirements of the sick pet.

[0023] If the target feeder is unavailable, the global management platform will automatically search for available spare cage feeders of the same specifications in the same ward, generate a list of alternative targets, and push a device malfunction alarm; if there are no available spare devices in the same ward, a device resource shortage alarm will be generated.

[0024] Furthermore, the queue rearrangement follows the rule of "priority first, time window compliance":

[0025] All tasks are sorted from highest to lowest feeding priority, with higher priority tasks taking the first feeding time slot.

[0026] The planned execution time for each feeding task must fall within its corresponding time window.

[0027] If multiple tasks conflict within the same time period after a task is inserted, the execution time of the task with higher priority is retained, and the execution time of the task with lower priority is postponed within its time window; if it still cannot be scheduled by the end of the time window, a time conflict alarm is generated.

[0028] Furthermore, during the migration window from the issuance of the unbinding command to the confirmation of acceptance of the task by the target feeder, both the original feeder and the target feeder simultaneously lock the feeding execution permissions of the corresponding sick pet; after the migration process is completed, only the target feeder is issued an unlocking command.

[0029] Before each feeding task for the sick pet, the target feeder initiates an on-site identity verification with the global management platform. Only after the verification is successful can the feeding action be initiated.

[0030] Furthermore, after a single feeding task is completed, the global management platform automatically verifies the execution result. Verification items include whether the feeding time is within the time window, whether the feeding amount is within the prescription error range, and whether there are any abnormal interruptions in the feeding process. If the verification fails, corresponding actions are taken according to the level of abnormality.

[0031] When a sick pet is discharged from the hospital, the global management platform automatically archives all feeding records for the pet, clears all tasks for the pet from the corresponding feeder, disconnects the pet from the cage and feeder, and marks the corresponding cage and feeder as idle and available.

[0032] Furthermore, a multi-pet feeder coordinated control device is characterized in that the device is deployed on a global management platform, comprising:

[0033] The pet medical record management module is used to generate globally unique pet identification identifiers, establish feeding prescriptions and medical restraint rules files bound to these identifiers, and connect to hospital inpatient and electronic medical record systems to achieve unified data management.

[0034] The equipment status management module is used to pre-store the one-to-one mapping relationship between cage positions and feeders, continuously collect the operation data of feeders, including the online status of feeders, task queues, food storage, and update the global equipment status pool in real time.

[0035] The location change verification module is used to receive pet location change events and sequentially complete the verification of the pet's identity in the hospital, the availability of the target cage, and the ward isolation adaptation. After all verifications are passed, the task migration process is officially started.

[0036] The task migration and scheduling module is used to issue unbinding instructions to the original feeder, clear all unexecuted tasks of the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution.

[0037] The data collection and synchronization module is used to receive execution data reported by each feeder, which carries the identification of sick pets, collect feeding data for the entire hospitalization cycle according to the sick pet's identification, and synchronize and update it to the corresponding electronic medical record.

[0038] This application also discloses an electronic device, including:

[0039] At least one processor; and

[0040] A memory communicatively connected to the at least one processor; wherein,

[0041] The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the above-described method for coordinated control of multiple pet feeders according to the present invention.

[0042] Beneficial Effects: This invention breaks the traditional static binding model of tasks and devices through mechanisms such as real-time location change sensing, automatic task unbinding and reordering, and multi-device collaborative interlocking. When sick pets are transferred between cages or wards, the feeding task automatically migrates synchronously with the pet, eliminating the need for manual adjustment of feeder parameters throughout the process. This avoids the problem of repeated feeding from the original cage feeder and prevents the omission of tasks in the new cage, reducing the feeding error rate in cage transfer scenarios to near zero, significantly reducing the operational burden on nursing staff, and significantly improving the safety of inpatient nursing.

[0043] This invention uses the pet's identity as the core for data storage and aggregation. All feeding execution data and food intake monitoring data are permanently attributed to the individual pet and are unaffected by changes in feeders. The feeding data throughout the pet's hospitalization forms a continuous and complete record chain, which is automatically synchronized to the electronic medical record system. This provides accurate and continuous data support for clinical condition assessment and nutritional plan adjustments, fully complying with the requirements for standardized management of pet medical records.

[0044] This invention stores all clinical medical constraint rules uniformly in the pet's global file. During task migration, these rules are automatically extracted and used as the sole basis for reordering, eliminating the need for manual reconfiguration on new devices. The reordering process strictly adheres to the original priority, time window, and other rules, ensuring a high degree of consistency between the feeding plan and clinical medical requirements. This avoids rule omissions or parameter deviations caused by manual reordering, while significantly improving scheduling efficiency after cage transfer, making it suitable for the high-frequency turnover inpatient scenarios of veterinary hospitals.

[0045] This invention establishes a triple protection mechanism: location change legality verification, dual-device interlocking during migration transition, and pre-execution identity verification. This mechanism prevents feeding errors throughout the entire process from triggering and migration to execution. It avoids erroneous migrations caused by misoperation, eliminates feeding conflicts during the migration window, and prevents misfeeding due to mismatch between sick pets and their cages, thus comprehensively constructing a safe protection system for hospital feeding.

[0046] This invention is specifically designed for the unique scenario of inpatient care in pet hospitals, addressing industry pain points that general home feeding systems and fixed-feeding systems cannot cover. Through the coordinated operation of multiple feeders throughout the hospital, it achieves automated and intelligent management of the entire feeding and care process, effectively reducing manual care costs, improving the standardization of care, and facilitating the digital upgrade of inpatient care in pet hospitals. Attached Figure Description

[0047] Figure 1 This is a flowchart of the collaborative control method for multiple pet feeders according to the present invention;

[0048] Figure 2 This is a flowchart illustrating the creation and global management of digital files for feeding sick pets in an embodiment of the present invention;

[0049] Figure 3 This is a flowchart illustrating the maintenance of the cage-feeder mapping relationship and the global device status monitoring in an embodiment of the present invention;

[0050] Figure 4 This is a flowchart illustrating the dynamic unbinding of feeding tasks across devices and matching with the target feeder in an embodiment of the present invention;

[0051] Figure 5 This is a flowchart illustrating the rearrangement of the feeding task queue based on the original medical constraint rules in an embodiment of the present invention. Detailed Implementation

[0052] The technical solutions of the present invention will be clearly and completely described below with reference to the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0053] This invention provides a method for coordinated control of multiple pet feeders, such as... Figure 1 As shown, the steps include:

[0054] When a sick pet is admitted to the hospital, the global management platform generates a globally unique identification identifier for the sick pet, establishes a feeding prescription and medical restraint rule file bound to this identifier, and connects to the hospital's inpatient and electronic medical record systems to achieve unified data management;

[0055] The global management platform pre-stores a one-to-one mapping relationship between cage positions and feeders, continuously collects the feeder's operating data, including the feeder's online status, task queue, and food storage, and updates the global device status pool in real time.

[0056] Upon receiving a pet location change event, the platform sequentially completes the verification of the pet's identity in the hospital, the availability of the target cage, and the adaptation to isolation in the ward. Once all verifications are passed, the task migration process is officially initiated.

[0057] The platform issues an unbinding command to the original feeder, clearing all unexecuted tasks for the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution.

[0058] Each feeder reports execution data carrying the pet's identification identifier. The platform collects feeding data for the entire hospitalization period according to the pet's identification and updates it synchronously to the corresponding electronic medical record.

[0059] The technical solution of the present invention will be further described in detail below with reference to specific embodiments. The following embodiments are only used to explain the present invention and are not intended to limit the scope of protection of the present invention.

[0060] Example 1: Collaborative Control Method for Cross-Ward Transfer Triggered by Medical Orders

[0061] This embodiment is applied to the inpatient department of a comprehensive pet hospital. The inpatient department is divided into three functional areas: a general ward, an isolation ward, and an intensive care unit, with a total of 65 standard inpatient cages. Each cage is equipped with one smart feeder. All feeders are connected to a global management platform deployed on the hospital's local server via the hospital's wireless LAN. The global management platform achieves bidirectional interoperability with the hospital's inpatient management system and electronic medical record system through a standardized API interface, enabling real-time data exchange.

[0062] The execution entity in this embodiment is a global management and control platform, and includes the following steps:

[0063] S1. Establishment and Global Management of Digital Feeding Records for Sick Pets: This step is the initialization step of the method and is executed when the sick pet is admitted to the hospital. It completes the establishment and unified management of all-dimensional feeding data with the sick pet's identity as the core.

[0064] Among them, the digital archive of feeding sick pets refers to an electronic archive that uses the individual sick pet as a unique index and stores all feeding-related data in a structured manner. It is the core data carrier for realizing the migration of tasks and data with sick pets.

[0065] Optionally, this step can be integrated with the hospital's inpatient management system to automatically retrieve the pet's basic information, eliminating the need for manual re-entry.

[0066] Specifically, such as Figure 2 As shown, the execution flow for this step is as follows:

[0067] The global management platform generates a globally unique pet identification ID for each pet that completes its hospitalization procedures. This ID is bound to the pet's hospitalization number and electronic medical record number and remains unchanged throughout the entire hospitalization period.

[0068] Healthcare professionals use the terminal interface of the global management platform to enter the feeding prescription information and clinical medical restraint rules corresponding to the sick pet. All entered data is directly linked to the corresponding pet's identification ID. The feeding prescription information includes the number of meals per day, the weight of each meal, the type of food, and the feeding method. The clinical medical restraint rules include the feeding time window for each meal, the feeding priority level, the fasting period, the medication-related feeding requirements, the feeding speed limit, and special care remarks.

[0069] The global management platform establishes an independent digital feeding file for each sick pet. The file is stored in a structured manner, and the stored content covers six categories of data: basic information of the sick pet, feeding prescription information, medical restraint rules, historical feeding execution records, historical feeding monitoring data, and abnormal events and location change logs.

[0070] The global management platform connects bidirectionally with the pet hospital's inpatient management system and electronic medical record system through standardized data interfaces. All data from the pet's feeding digital file is synchronized in real time to the corresponding nursing record section of the electronic medical record, ensuring that the feeding file data is consistent with the clinical medical data.

[0071] If changes to the clinical treatment plan during a pet's hospitalization result in changes to the feeding prescription or medical restraint rules, medical staff only need to modify the parameters in the corresponding pet's file on the global management platform. The changes will take effect immediately and globally, without needing to operate each feeder terminal individually.

[0072] It is understood that this step shifts the core carrier of feeding data from a single feeder to the identity of the sick pet, decoupling the data from the device and providing a unified data foundation for subsequent dynamic migration of tasks and continuous data collection. This replaces the traditional device-centric binding model at the architectural level.

[0073] S2. Real-time maintenance and equipment status monitoring of cage-feeder mapping relationship. This step is the basic step of equipment management in the method. It is continuously executed throughout the system operation to maintain the correspondence between cages and feeders in the entire facility and monitor the operating status of all feeders in real time.

[0074] Among them, the global device status pool refers to the unified data set maintained by the global management and control platform that aggregates the real-time operating status of all feeders, and is the core basis for task scheduling and device matching.

[0075] Optionally, the status reporting cycle of the feeder can be configured according to the actual needs of the hospital, with a default setting of 30 seconds; the disinfection status can be automatically triggered by the cage disinfection operation, without the need for manual marking.

[0076] Specifically, such as Figure 3 As shown, the execution flow for this step is as follows:

[0077] The overall management platform is pre-configured with a one-to-one mapping table between all cages and smart feeders in the hospital's inpatient department. Each mapping record includes the cage number, the ward it belongs to, the feeder device ID, and the physical installation location of the device. The cage numbers follow a unified coding rule across the hospital, clearly distinguishing different functional areas such as general wards, isolation wards, and intensive care units.

[0078] Each smart feeder maintains a long-term connection with the overall management platform via the facility's wired or wireless LAN, communicating in real time and reporting its operational status data to the platform at fixed intervals. This operational status data includes: device online status, local task queue status, remaining food reserves, disinfection status, fault status, and the status of monitoring sick pets in the current cage.

[0079] The global management platform updates the status data of all feeders in real time, constructs a global device status pool, and marks each feeder with five status tags: available, busy, offline, disinfected, and faulty. Among them, the disinfection status is triggered by the cage disinfection operation. Before the caregiver performs cage disinfection, the corresponding cage is marked as being disinfected via mobile terminal, and the corresponding feeder is simultaneously switched to the disinfection status, prohibiting any feeding tasks.

[0080] The global management platform automatically verifies the consistency of the cage-feeder mapping relationship daily. If equipment is replaced or cage function is adjusted, administrators can modify the mapping relationship in the platform backend, and the modification will take effect immediately after completion.

[0081] It is known that this step has enabled unified and visualized management of all feeder resources in the hospital, allowing real-time monitoring of the operating status and availability of each device, and providing accurate status information for matching target devices in subsequent task migrations.

[0082] S3. Real-time perception and legality verification of sick pet location change events. This step is the trigger entry step for task migration. It is triggered in real time when the sick pet changes location, and completes multi-source collection and multi-layer compliance verification of change events.

[0083] Among them, legality verification refers to the multi-level verification of the validity and compliance of location change events, which is the core line of defense against misoperation and illegal transfer.

[0084] Optionally, the triggering channel for location change events can be expanded according to the hospital's level of informatization, such as supporting linkage triggering with access control systems.

[0085] Specifically, the execution flow for this step is as follows:

[0086] The global management platform supports three types of location change event triggering channels, including:

[0087] Manual scanning triggers a location change event when nursing staff perform cage transfer operations by using an in-hospital mobile terminal to scan the QR code on the pet's identification wristband and the QR code of the target cage, submitting a cage transfer request.

[0088] When the inpatient system pushes medical orders, such as transferring the pet to another cage, transferring the pet to another ward, or sending the pet out for examination, the inpatient management system automatically pushes a location change event to the global management platform. The event includes the pet ID, the target cage number, and the specified effective time.

[0089] When a sick pet returns from an outpatient check-up, the nursing staff scans the pet's identification wristband and the QR code indicating its return to its cage, triggering a location return event.

[0090] Upon receiving a location change event, the global management platform immediately initiates a four-layer validity check. An event is considered valid only if all checks pass, including:

[0091] Verify the identity of the sick pet to confirm that the pet ID corresponding to the event is in the hospital and that there is a valid feeding record.

[0092] Target cage verification confirms that the target cage number exists in the system, the corresponding feeder is available, and there are no other sick pets occupying it at present.

[0093] The ward adaptation verification confirms that the ward to which the target cage belongs meets the isolation management requirements based on the isolation level of the sick pet's condition, and prohibits the transfer of pets with infectious diseases to ordinary ward cages;

[0094] Time validity check: If the event carries a specified effective time, check the reasonableness of the effective time and prohibit retrospective location changes.

[0095] If all verifications pass, the global management platform marks the event as a valid event and immediately initiates the subsequent task migration process; if any verification fails, the change event is immediately rejected, and a clear reason for the verification failure and operation prompts are returned to the submitting terminal, without triggering any subsequent migration actions.

[0096] After verification, the global management platform records the complete information of this location change event in the feeding digital file of the corresponding sick pet, including the change trigger time, original cage number, target cage number, operator, and trigger source, forming a traceable location change log.

[0097] It is understood that this step accurately senses changes in the location of the sick pet through multiple channels, and combines multi-layer verification to eliminate illegal changes and misoperations, ensuring the accuracy and compliance of task migration from the source and avoiding feeding errors caused by operational mistakes.

[0098] S4. Dynamic unbinding of feeding tasks across devices and matching with the target feeder. This step is the core execution step of task migration. It is executed immediately after the location change event is verified, and completes the complete unbinding of the feeding task from the original feeder and the precise matching with the target feeder.

[0099] Task unbinding refers to removing the feeding task corresponding to the sick pet from the local queue of the original feeder and locking the execution permission. It is the core means to avoid repeated feeding on the original device.

[0100] Optionally, if there is a task in progress when unbinding, it can support resume feeding from breakpoint, and synchronize the amount of food already fed to the target feeder to generate a supplementary feeding task.

[0101] Specifically, such as Figure 4 As shown, the execution flow for this step is as follows:

[0102] The global management platform uses the sick pet ID in the location change event to query the original cage number and the corresponding original feeder device ID that the sick pet is currently bound to.

[0103] The global management platform issues a formal task unbinding command to the original feeder, carrying the corresponding pet's identification ID. Upon receiving the unbinding command, the original feeder immediately performs three simultaneous operations, including:

[0104] Remove all unexecuted feeding tasks corresponding to the sick pet from the local task queue and clear the relevant task instructions in the local cache;

[0105] Lock the feeding permissions for the sick pet, and prevent any feeding actions from being initiated even if there are any residual instructions that have not been cleared.

[0106] The system sends a successful unbinding response to the global management platform and reports the execution progress of all tasks for the sick pet in the current queue, clearly distinguishing between the three states: completed, in progress, and not yet executed.

[0107] If a feeding task is in progress when the device is unbound, the original feeder will immediately stop feeding, accurately record the weight of the food already fed, and report the task interruption status and the amount of food fed to the global management platform. The platform will then record this information in the corresponding pet's feeding digital file.

[0108] The global management platform matches the target feeder device ID with the target cage number, retrieves real-time data from the global device status pool, and performs a secondary availability check on the target feeder to confirm that its online status is normal, it is available, and the food reserves meet the feeding prescription requirements of the sick pet.

[0109] If the target feeder passes the secondary availability check, it is officially confirmed as the target device for this task migration; if the target feeder is unavailable, including offline, faulty, or insufficient food storage, the global management platform automatically searches for available spare cage feeders of the same specifications in the same ward, generates a list of alternative targets, pushes equipment abnormality alarms to nursing staff, and completes target matching after manual confirmation; if there are no available spare devices in the same ward, an equipment resource shortage alarm is generated, and nursing staff are notified to perform manual feeding intervention.

[0110] It is understood that this step achieves a quick and complete debinding of the feeding task from the original feeder, avoiding repeated feeding caused by the original device continuing to perform the task; at the same time, it accurately matches available target feeders through secondary verification, ensuring the execution basis after the task migration.

[0111] S5. Feeding task rearrangement and queue insertion based on the original constraint rules. This step is a scheduling adaptation step, which is executed after the target feeder is matched. The migration task is inserted into the task queue of the new device according to the original medical constraint rules.

[0112] Queue rearrangement refers to the process of integrating migration tasks into the original task queue of the target feeder and reordering them. The core principle is to ensure the complete continuation of the original medical constraint rules.

[0113] Optionally, the queue rearrangement algorithm can support multi-dimensional constraint extensions, such as feeder hardware performance constraints and food type matching constraints.

[0114] Specifically, such as Figure 5 As shown, the execution flow for this step is as follows:

[0115] The global management platform extracts all clinical medical constraint rules for the corresponding sick pet from its feeding digital file, including feeding priority level, time window range for each meal, and fasting period restrictions, which serve as the sole basis for determining the task reordering.

[0116] The global management platform retrieves the current local task queue data of the target feeder, which contains other sick pet feeding tasks and execution time plans that have been sorted.

[0117] The global management platform, following the core principles of "priority first, time window compliance," inserts the feeding tasks to be migrated into the task queue of the target feeder, completing the queue rearrangement. The specific execution standards for the rearrangement rules are as follows:

[0118] Priority sorting rules: all tasks are sorted from high to low according to feeding priority level, and high priority tasks occupy the feeding execution time first;

[0119] The time window constraint rule stipulates that the planned execution time of each feeding task must fall within its corresponding time window, and must not be earlier than the earliest start time or later than the latest end time.

[0120] The conflict handling rules stipulate that if multiple tasks conflict within the same time period after a task is inserted, the execution time of the task with higher priority will be reserved, and the task with lower priority will be postponed within its time window. If the task still cannot be scheduled by the end of the time window, a time conflict alarm will be generated to notify the nursing staff to manually adjust the prescription or task order.

[0121] After the queue is rearranged, the global management platform will send the updated complete task queue to the target feeder. The target feeder will update its local task queue and send a confirmation of successful task reception to the platform.

[0122] The global management platform synchronously updates the task execution plan in the digital file of feeding sick pets, records the execution equipment and adjusted execution time after the task migration, and maintains global consistency of the plan data.

[0123] It is known that this step fully continues the original clinical medical constraints during the task migration process, automatically rearranges the task queue of the new equipment, and does not require manual reconfiguration of parameters, which improves scheduling efficiency and ensures the consistency between the feeding plan and clinical medical requirements.

[0124] S6. Multi-device collaborative migration transition interlock and pre-execution identity verification: This step is an error prevention step that takes effect throughout the entire task migration process and before task execution. Through dual-device collaborative interlock and pre-execution identity verification mechanism, it prevents the risk of duplicate feeding and incorrect feeding.

[0125] Among them, the migration transition interlock refers to the mechanism that locks the feeding permissions of the sick pet by both the original feeder and the target feeder during the migration window, in order to eliminate feeding blind spots during the migration process.

[0126] Optionally, the response time for pre-verification is configurable. By default, the platform is required to return the verification result within 1 second to avoid affecting the feeding timeliness.

[0127] Specifically, the execution flow for this step is as follows:

[0128] The migration transition interlock mechanism works as follows: from the moment the global management platform issues the unbinding command to the original feeder until the target feeder confirms receipt of the task and the sick pet's presence is confirmed, both the original and target feeders simultaneously lock the feeding execution permissions for the sick pet during the entire migration window. Neither party may initiate a feeding action. After the entire migration process is completed, the global management platform only issues an unlock command to the target feeder, allowing the target feeder to execute the corresponding task in the queue normally.

[0129] Before execution, an identity verification mechanism is implemented. Before each feeding task for the sick pet, the target feeder must first send an on-site identity verification request to the global management platform. The verification content includes whether the sick pet ID corresponding to the current cage space is consistent with the sick pet ID to which the task belongs; whether the sick pet is currently in the hospital; and whether the feeding task is in a valid state and has not been canceled or adjusted.

[0130] The global management platform returns the verification results within the set time limit. The target feeder can only start the feeding action if all three verifications pass. If any verification fails, the feeder will immediately cancel the task execution, report the abnormal event to the platform, and push a verification notification to the nursing terminal.

[0131] For feeding tasks interrupted during migration, the global management platform accurately calculates the remaining amount to be fed based on the weight already delivered and the total weight of the prescription, and generates a supplementary feeding task in the target feeder. The supplementary feeding task also follows the original constraint rules and pre-execution verification mechanism.

[0132] It is known that this step eliminates the feeding blind spot during the migration window by interlocking the two devices during the transition period; and avoids misfeeding caused by mismatch between cage and sick pet by real-time identity verification before execution, thus ensuring feeding accuracy in all aspects of the process.

[0133] S7. Continuous collection and synchronization of all feeding data based on the pet's identity with the medical record. This step is a data management step that is continuously executed throughout the system operation to aggregate all feeding data according to the pet's identity, ensuring the continuity and integrity of the electronic medical record feeding records.

[0134] Among them, continuous data collection refers to the process of uniformly aggregating feeding data generated by different devices according to the identity of sick pets and storing it in order of time. The core is to decouple data from devices and bind it to identity.

[0135] Optionally, the data synchronization cycle can be configured according to the hospital's medical record management requirements, supporting both minute-level synchronization and real-time synchronization modes.

[0136] Specifically, the execution flow for this step is as follows:

[0137] During the feeding process, each feeder collects complete feeding execution data and feeding monitoring data in real time, including actual feeding time, actual feeding weight, feeding duration, feeding time for sick pets, amount of remaining food, and any abnormal events. All reported data includes the identification ID of the sick pet associated with the corresponding task, rather than just the feeder's own device ID.

[0138] After receiving the data reported by the feeder, the global management platform directly collects it into the corresponding pet's feeding digital file based on the pet's identification ID carried in the data. This data is stored continuously in chronological order with historical data, forming a continuous feeding data chain covering the entire hospitalization cycle.

[0139] Regardless of how many feeders are used during a pet's hospitalization, all feeding data is attributed to the same pet's file, ensuring data storage continuity regardless of device changes. The global management platform automatically sorts all data by time, generating continuous feeding and care records.

[0140] The global management platform synchronizes new data from the pet feeding digital files to the hospital's electronic medical record system according to the set synchronization cycle, and adds it to the corresponding pet's inpatient nursing record section.

[0141] Medical staff can directly access complete feeding data for a sick pet throughout its entire hospital stay through the electronic medical record system, without needing to retrieve data across devices or systems. The data is presented as a unified and continuous nursing record.

[0142] It is understood that this step completely solves the data breakage problem caused by equipment changes, realizes the permanent binding of feeding and care data with the pet's identity, ensures the integrity and continuity of electronic medical records, and meets the requirements of clinical diagnosis and treatment and standardized management of medical records.

[0143] S8. Feeding task execution closed-loop verification. This step is performed after each feeding task is completed and the entire life cycle is completed when the sick pet is discharged from the hospital, realizing the verification of execution results, abnormal handling and resource release.

[0144] Closed-loop verification refers to verifying the consistency between the feeding execution results and the prescription requirements and constraint rules, which is the last line of defense to ensure the quality of feeding care.

[0145] Optionally, abnormal events can automatically trigger different handling procedures based on their severity level, supporting multi-level alarms and tiered push notifications.

[0146] Specifically, the execution flow for this step is as follows:

[0147] After a single feeding task is completed, the target feeder will report the complete execution result data packet to the global management platform.

[0148] The global management platform retrieves prescription requirements and constraint rules from the pet's feeding records and automatically verifies the execution results. Verification items include whether the feeding time is within the time window, whether the feeding amount is within the prescription error range, and whether there are any abnormal interruptions in the feeding process.

[0149] If the verification passes, the task is marked as completed, and the pet's medical records and electronic medical records are updated synchronously. If the verification fails, it is determined to be an abnormal event, and corresponding actions are taken according to the level of abnormality.

[0150] General abnormalities: such as feeding amount deviation exceeding the allowable range or feeding time slightly exceeding the time window, the system will automatically record the abnormality details and generate a routine nursing reminder to be pushed to the responsible nursing terminal;

[0151] Serious anomalies: such as feeding failure, sick pet not eating, or equipment failure causing feeding interruption, the system will immediately generate a high-priority alarm and push it to the ward nursing station and the responsible medical staff terminal. At the same time, the subsequent feeding tasks for the sick pet will be suspended until manual investigation and handling.

[0152] The handling process and results of all abnormal events are recorded in the pet's feeding record, forming a complete event traceability chain.

[0153] When a sick pet is discharged from the hospital, the global management platform receives the discharge notification from the hospitalization system and automatically performs the following closing operations: archives all feeding records of the sick pet, clears all tasks for the sick pet from the corresponding feeder, disconnects the sick pet from the cage and feeder, and marks the corresponding cage and feeder as vacant and available, waiting for the next sick pet to move in.

[0154] It is understood that this step forms a complete closed loop from the issuance and execution of the feeding task to its verification, enabling timely detection and handling of abnormalities and ensuring the quality of feeding and care; at the same time, it completes the closed loop of the entire hospitalization cycle for sick pets, realizing the automatic release and recycling of equipment resources.

[0155] Based on a specific clinical scenario, the operation process of this embodiment is as follows: An adult poodle suffering from acute gastroenteritis, hospital number ZY2024060037, pet identification ID PET00319, was initially admitted to cage slot A07 in the general ward, corresponding to feeder device ID FWQ-A07. The pet's feeding prescription was 3 meals a day, fed at 8:00, 12:00, and 18:00, with 80g of enteric prescription food per meal. The feeding time window was 30 minutes before and after the scheduled time, the feeding priority was normal, and the constraint was to administer oral medication half an hour after meals. On the second day of hospitalization, due to the dog's worsening vomiting and dehydration symptoms, the attending veterinarian issued a transfer order, transferring the pet to cage slot ICU-08 in the intensive care unit, corresponding to feeder ID FWQ-ICU08, with the transfer taking effect at 10:15 on the same day.

[0156] When the sick dog PET00319 was admitted to the hospital, the global management platform generated a unique identification ID for it, established a dedicated digital feeding file, entered complete feeding prescriptions and medical restraint rules, and linked it to the corresponding electronic medical record number. After the caregivers confirmed that the sick dog was admitted to cage A07, the global management platform issued the daily feeding tasks for the sick dog to the FWQ-A07 feeder. At 8:00 AM that day, FWQ-A07 performed breakfast feeding as planned, initiating an on-site identity verification with the platform before execution. After successful verification, feeding was initiated, accurately dispensing 80g of prescription food. After feeding, FWQ-A07 reported the execution data along with the sick dog ID PET00319 to the management platform. The platform then collected the data into the sick dog's feeding file and synchronized it to the electronic medical record system in real time.

[0157] At 10:15 that day, the attending physician issued a transfer order to the intensive care unit in the inpatient management system, and the system automatically pushed a location change event to the global management platform. After receiving the event, the global management platform sequentially completed the verification of the sick pet's identity, target cage location, ward adaptation, and time validity. After all verifications passed, the platform recorded the event in the location change log of the sick pet's feeding file, and officially started the task migration process.

[0158] The global management platform issued a task unbinding command to the original feeder FWQ-A07. Upon receiving the command, FWQ-A07 removed the two unexecuted tasks (12:00 lunch and 18:00 dinner) corresponding to PET00319 from its local task queue, locked the feeding execution permission for the sick pet, and reported the successful unbinding and task execution progress to the platform. Subsequently, the global management platform matched the target feeder FWQ-ICU08. After a second availability check confirmed that the device was online and had sufficient food reserves, it was officially determined as the target device for migration.

[0159] The global management platform extracts all medical constraint rules from PET00319's feeding digital file, retrieves the current local task queue of FWQ-ICU08, and reorders the queue according to the rule of "priority first, time window compliance," scheduling the lunch task for 12:00 and the dinner task for 18:00, both meeting the time window requirements and without conflict. After the reordering is completed, the platform distributes the updated task queue to FWQ-ICU08, synchronously updating the task execution plan in the pet's file.

[0160] During the migration window, both FWQ-A07 and FWQ-ICU08 simultaneously locked the feeding permissions for PET00319. After the migration process was completed, the global management platform only issued an unlock command to FWQ-ICU08. Before 12:00 noon on the same day, FWQ-ICU08 initiated an on-presence identity verification before performing the lunch task. After all three verifications passed, feeding was initiated, accurately dispensing 80g of prescription food. After feeding, FWQ-ICU08 reported the execution data along with the sick pet's ID to the platform. The platform then collected the feeding data for this lunch into the sick pet's feeding file, arranging it chronologically with the previous breakfast data to form a continuous feeding record chain, and synchronizing it in real time to the electronic medical record system.

[0161] The global management platform automatically verifies the lunch execution results, confirming that the feeding time and amount meet the requirements, and marks the task as completed. At 18:00 that day, FWQ-ICU08 completes dinner feeding according to the same process, and the corresponding data is synchronously collected into the pet's file. When the sick dog is discharged after recovery, the global management platform receives the discharge notification from the hospitalization system, automatically archives all feeding records for PET00319, clears all tasks for that sick dog in FWQ-ICU08, disconnects the association, and marks the cage and feeder as idle.

[0162] Example 2: Collaborative Control Method for RFID Automatic Sensing Turbine Rotating Cage

[0163] This embodiment is an alternative implementation of Embodiment 1. The core difference is that the sensing method for the change of the sick pet's location adopts an RFID automatic identification scheme, while the rest of the control logic is completely consistent with Embodiment 1.

[0164] Among them, the RFID automatic identification solution refers to a technical solution that uses RFID tags worn by sick pets and RFID readers installed in cages to automatically sense changes in location, which can further improve the level of automation.

[0165] Specifically, in this embodiment, each sick pet wears an identification wristband with a built-in UHF RFID tag, and a fixed RFID reader is installed at the entrance of each cage. The reader communicates with the global management platform in real time and can automatically identify the tag information of sick pets in the cage. When the reader in the original cage detects that the sick pet's tag has disappeared, and the reader in the target cage detects that the sick pet's tag has appeared, the system automatically determines that the sick pet's location has changed and automatically pushes the location change event to the global management platform, without requiring caregivers to manually scan the code.

[0166] After the event is pushed out, all subsequent processes, such as legality verification, task unbinding, target matching, queue rearrangement, and data collection, are completely consistent with the execution standards of Example 1.

[0167] It is understood that this embodiment can further reduce the workload of nursing staff, and is especially suitable for intensive care units with extremely high turnover rates. At the same time, it can avoid the problems of missed or incorrect operations caused by manual scanning.

[0168] Example 3: Multi-Pet Feeder Coordinated Control Device

[0169] This embodiment provides a collaborative control device for multiple pet feeders. The device is deployed on a global management platform to execute the control method described in Embodiment 1. The device adopts a modular architecture, with each module's function corresponding to a specific method step, including:

[0170] The pet medical record management module is used to generate globally unique pet identification identifiers, establish feeding prescriptions and medical restraint rules files bound to these identifiers, and connect to hospital inpatient and electronic medical record systems to achieve unified data management.

[0171] The equipment status management module is used to pre-store the one-to-one mapping relationship between cage positions and feeders, continuously collect the operation data of feeders, including the online status of feeders, task queues, food storage, and update the global equipment status pool in real time.

[0172] The location change verification module is used to receive pet location change events and sequentially complete the verification of the pet's identity in the hospital, the availability of the target cage, and the ward isolation adaptation. After all verifications are passed, the task migration process is started.

[0173] The task migration and scheduling module is used to issue unbinding instructions to the original feeder, clear all unexecuted tasks of the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution.

[0174] The collaborative interlock control module is used to control the interlock between the two devices during the migration transition period, as well as the on-site identity verification before feeding is executed;

[0175] The data collection and synchronization module is used to receive the execution data reported by each feeder, which carries the identification of the sick pet, collect the feeding data of the entire hospitalization cycle according to the sick pet's identity, and synchronize and update it to the corresponding electronic medical record.

[0176] The anomaly handling module is used to automatically verify feeding results, manage anomaly classification alarms and handling records, and archive and release resources when sick pets are discharged from the hospital.

[0177] The device described in this embodiment is based on the same technical concept as the aforementioned method embodiment and has the same technical effects as the method embodiment, so it will not be described again here.

[0178] Example 4: Electronic Devices and Computer-Readable Storage Media

[0179] This embodiment provides an electronic device, including a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements all the steps of the coordinated control method for multiple pet feeders described in Embodiment 1.

[0180] The electronic device may be a server, industrial control computer or other device with computing and processing capabilities, and the memory may include high-speed random access memory or non-volatile memory.

[0181] This embodiment also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements all the steps of the multi-pet feeder coordinated control method described in Embodiment 1.

[0182] The storage medium can be any medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory, random access memory, magnetic disk, or optical disk.

[0183] Finally, it should be noted that the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for coordinated control of multiple pet feeders, characterized in that, Includes the following steps: When a sick pet is admitted to the hospital, the global management platform generates a globally unique identification identifier for the sick pet, establishes a feeding prescription and medical restraint rule file bound to this identifier, and connects to the hospital's inpatient and electronic medical record systems to achieve unified data management; The global management platform pre-stores a one-to-one mapping relationship between cage positions and feeders, continuously collects the feeder's operating data, including the feeder's online status, task queue, and food storage, and updates the global device status pool in real time. Upon receiving a pet location change event, the platform sequentially completes the verification of the pet's identity in the hospital, the availability of the target cage, and the adaptation to isolation in the ward. Once all verifications are passed, the task migration process is officially initiated. The platform issues an unbinding command to the original feeder, clearing all unexecuted tasks for the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution. Each feeder reports execution data carrying the pet's identification identifier. The platform collects feeding data for the entire hospitalization period according to the pet's identification and updates it synchronously to the corresponding electronic medical record.

2. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, The triggering channels for the pet location change event include: Manual scanning trigger: When nursing staff perform cage transfer operations, they use an in-hospital mobile terminal to scan the QR code on the pet's identification wristband and the QR code of the target cage, and submit a cage transfer application to trigger a location change event. Inpatient system medical order push trigger: When clinicians issue medical orders such as transfer to another ward, transfer to another department, or outpatient examination, the inpatient management system automatically pushes the location change event to the global management platform; Return from an outpatient check-up trigger: When a sick pet returns to the ward after an outpatient check-up, the caregiver scans the pet's identification wristband and the QR code for returning to its cage, triggering a location return event.

3. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, The validity check also includes a time validity check: if the event carries a specified effective time, the validity of the effective time is checked, and retrospective location changes are prohibited; all checks must pass for the event to be considered valid, and if any check fails, the change event is rejected and the reason for failure is returned.

4. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, Upon receiving the unbinding command, the original feeder simultaneously performs the following operations: Remove all unexecuted feeding tasks for the corresponding sick pet from the local task queue and clear the relevant task commands from the local cache; Lock the feeding permissions for the sick pet and prohibit any feeding actions from being initiated; The system sends a successful unbinding response to the global management platform and reports the execution progress of all tasks for the sick pet in the current queue. If a feeding task is in progress when the device is unbound, the original feeder will immediately pause the feeding action, record the weight of the food already fed, and report the task interruption status and the amount of food fed to the global management platform.

5. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, When matching a target feeder, the global management platform retrieves real-time data from the global device status pool to perform a secondary availability check on the target feeder, confirming that its online status is normal, it is in an available state, and its food reserves meet the feeding prescription requirements of the sick pet. If the target feeder is unavailable, the global management platform will automatically search for available spare cage feeders of the same specifications in the same ward, generate a list of alternative targets, and push a device malfunction alarm; if there are no available spare devices in the same ward, a device resource shortage alarm will be generated.

6. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, The queue reordering follows the rule of "priority first, time window compliance": All tasks are sorted from highest to lowest feeding priority, with higher priority tasks taking the first feeding time slot. The planned execution time for each feeding task must fall within its corresponding time window. If multiple tasks conflict within the same time period after a task is inserted, the execution time of the task with higher priority is retained, and the execution time of the task with lower priority is postponed within its time window; if it still cannot be scheduled by the end of the time window, a time conflict alarm is generated.

7. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, During the migration window from the issuance of the unbinding command to the confirmation of acceptance of the task by the target feeder, both the original feeder and the target feeder simultaneously lock the feeding execution permissions of the corresponding sick pet. Once the migration process is complete, an unlock command is only sent to the target feeder; Before each feeding task for the sick pet, the target feeder initiates an on-site identity verification with the global management platform. Only after the verification is successful can the feeding action be initiated.

8. The method for coordinated control of multiple pet feeders according to claim 1, characterized in that, After a single feeding task is completed, the global management platform automatically verifies the execution result. Verification items include whether the feeding time is within the time window, whether the feeding amount is within the prescription error range, and whether there is any abnormal interruption in the feeding process. If the verification fails, corresponding actions are taken according to the level of abnormality. When a sick pet is discharged from the hospital, the global management platform automatically archives all feeding records for the pet, clears all tasks for the pet from the corresponding feeder, disconnects the pet from the cage and feeder, and marks the corresponding cage and feeder as idle and available.

9. An apparatus utilizing the method for coordinated control of multiple pet feeders according to any one of claims 1 to 8, characterized in that, The device is deployed on a global management platform and includes: The pet medical record management module is used to generate globally unique pet identification identifiers, establish feeding prescriptions and medical restraint rules files bound to these identifiers, and connect to hospital inpatient and electronic medical record systems to achieve unified data management. The equipment status management module is used to pre-store the one-to-one mapping relationship between cage positions and feeders, continuously collect the operation data of feeders, including the online status of feeders, task queues, food storage, and update the global equipment status pool in real time. The location change verification module is used to receive pet location change events and sequentially complete the verification of the pet's identity in the hospital, the availability of the target cage, and the ward isolation adaptation. After all verifications are passed, the task migration process is officially started. The task migration and scheduling module is used to issue unbinding instructions to the original feeder, clear all unexecuted tasks of the corresponding sick pet in its local area; after matching an available target feeder, the queue is rearranged according to the original constraint rules, and the tasks are sent to the target feeder for execution. The data collection and synchronization module is used to receive execution data reported by each feeder, which carries the identification of sick pets, collect feeding data for the entire hospitalization cycle according to the sick pet's identity, and synchronize and update it to the corresponding electronic medical record.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements all the steps of the multi-pet feeder coordinated control method according to any one of claims 1 to 8.

Images